[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] Shared Libs
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