From fnaumann@mail.cs.uni-magdeburg.de Tue Aug 24 13:45:06 2004 Message-ID: <412B26D5.30406@seznam.cz> Date: Tue, 24 Aug 2004 13:30:29 +0200 From: Standa Opichal User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@fishpool.com Subject: Re: [MiNT] Shared Libs References: <1093209407.25052.9.camel@localhost> <20040823223705.61ea9ae3.mandin.patrice@wanadoo.fr> <412A657A.9070907@seznam.cz> <412AF784.8090809@users.sf.net> In-Reply-To: <412AF784.8090809@users.sf.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Delivered-To: mint@fishpool.com Delivered-To: mint@lists.fishpool.fi X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: opichals@seznam.cz Precedence: bulk List-help: List-unsubscribe: List-ID: X-List-ID: X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel X-Milter: ClamAV 0.70/0.70kjel X-Milter: milter-regex 1.5jel Hi Guillame! Guillaume Déflache wrote: > Standa Opichal wrote: > >> When I was thinking about it it seemed to me like that the .a archives >> (static libraries comprised of .o files) can serve as dynamicaly >> loadable library (for the case you don't need to share the code >> actually, of course, otherwise you would need -fPIC and other stuff to >> be fine, perhaps). It already contains (IMO) all information we need >> (symbol tables, relocation tables, ...). > > I agree 100%. In fact that was the thing I told you I was working on > some months ago... I started to do a very early prototype of it, in 68k > assembler sadly! Hey, what is the status today? >> So why not to just modify the .PRG binary so that it can contain the >> library list to load 'and we are done' (although it might be quite >> piece of investigation for binutils newbie) for now... Later, when we >> have VM (if ever), we can also implement true .so libs if required. >> Perhaps a symlinks .so -> .a libs would be just enought to distinguis >> whether the ld can link dynamicaly or not for now. >> >> Opinions? Corrections? > > The way I see it it is that the developper should not need to do > anything special to use shared libraries. Agreed. > So I would be tempted to try define a minimalistic approach to library > sharing: > > Libraries are contained in static libraries files (*.a, *.lib, etc.) or > simply object files (*.o, *.obj, etc.). Nothing special compared to > static linking. Yes. > To use them, you simply have to use a special *program* (*not* a startup > code, like crt0.o or its variants) and you are done. This program will > load all your libraries, and even your main code will have to be a > library (because it has unresolved references to other libraries in it). > Ideally the main code could be concatenated (no need for a special > "linker" then) in its raw form to this launcher to avoid clutter. In other words: Create a .PRG that is able to dynamicaly link several libraries (one of which is appended to the tail of that itself). But I view this as a crt0.o piece of the .PRG actually and the rest of that file would be the .o files of the main code. Correct? > There is no notion of namespace, symbol versioning or whatever. Sure, there were never any of these in C AFAIK. > LBNL: Only libraries without global variables will be shared! Else > we would need VM to ensure separate instances of the variable. > How do we ensure this? Forbidding libraries with *external* symbols > in DATA or BSS section could do the job. Anyway a clean API should > *never* expose variables, only functions... For extra safety, one > should prevent writes in TEXT section memory blocks, just in case... To start with something simple we can do the loader which just loads all the other libs to a private process context (no sharing at all). Later we will see what we can do about it more. best regards STanda