[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A portable way to link in all objects
From: |
Ronald Landheer-Cieslak |
Subject: |
Re: A portable way to link in all objects |
Date: |
Tue, 10 Jun 2003 17:59:30 +0200 (CEST) |
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
>