Re: A portable way to link in all objects

[Ronald Landheer-Cieslak]

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
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/libtool
>