On Tue, 3 Jun 2003, Robert Boehne wrote: > Ronald, > > Libtool purposely does not support linking static libs into shared libs > when it can help it, so even if a patch with a proper copyright > assignment was posted, it wouldn't get past me. The idea I was looking at is not linking static libs into shared ones: it's linking static libs and shared libs into executables and having them behave the same regardless of the platform. AFAIK, the gcc attributes (constructor & destructor) are pretty platform-independant (i.e. if you use gcc, they'll probably/portably work).
There may also be other side-effects to the difference between how shared libraries are linked vs. how static libraries are linked (when dlopening the executable, for exemple). > I don't want libtool to have to drag around (i.e. maintain) code for > 10,000 different platform-specific features that aren't available on all > common systems. It makes it harder for Libtool to do its real job, > which is building well-designed software on any platform you can get > your hands on. I can see your point in not wanting to drag around specific code of various different platforms (even though AFAICT there's already a lot of specific code in Libtool..). Are there any platforms that don't support linking in entire static libraries? (the documentation for the --whole-archive option of GNU ld doesn't say anything about it being specific to any kind of platform). I don't want to nag, but I don't quite see how the "don't link shared libs to static libs" argument comes into play. rlc > Ronald Landheer-Cieslak wrote: > > > > Hello all, > > > > I am looking for a way to portably tell libtool to link in all objects of > > a given static library. Basically, my problem is this: > > > > I have an object file containing "constructor" and "destructor" > > functions, which are not called from any program using my library, but > > which are run automagically at startup (constructor) or shutdown > > (destructor) time. Under gcc, this is implemented using > > __attribute__((constructor)) resp. __attribute__((destructor)). > > > > This scheme works like a charm when my libraries are shared: the program > > using the library loads the library into memory and the proper functions > > are automagically run. However, when the library is not shared, the object > > files containing the constructor and destructor functions don't get linked > > into the program, because the program has no business calling anything in > > the corresponding source file - and so doesn't. Hence, the constructor > > function doesn't get called at startup and all hell breaks loose. > > > > One way I've thought about to work around this thing is to make a static > > object of which the constructor does its thing, resp. the destructor does > > its thing, for which I put an "extern" in the library's (only) API header > > file. This will probably work and, as most of the library is written in > > C++ anyway, will probably do as a solution. However, I was hoping there is > > some option I've overlooked in Libtool that makes static libraries and > > shared libraries behave the same in this respect - i.e. be linked > > completely into an executable (considering a shared library an executable > > as per the Libtool paradigm). Though this option would not be > > "satisfactory" in all situations, it would help here. > > > > I know of the --whole-archive and --no-whole-archive linker options, but > > they probably won't help much for my problem, mostly because: > > 1. having to link the entire archive is a library attribute possibly > > unknown to users of the library > > 2. the order in which libraries are linked and the options passed to them > > are, and should be, the domain of Libtool *only* - I shouldn't have to > > mess with that. > > Hence, the option should be passable at the link stage *of the library*. > > > > My questions (finally): > > * does this feature already exist? > > | + if so: where is it documented? > > | - if not: would it be considered useful? > > | | + if so: would you consider patches *without* a copyright waiver for > > | | | FSF? (don't have one - can't get one) > > | | | - if not: would someone else consider implementing it? (I'd be happy > > | | | | to help out, if I could without infringing copyright restrictions) > > | | - if not: why not? > > > > Thanks! > > > > rlc > > > > _______________________________________________ > > Libtool mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/libtool > _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
