This is the mail archive of the
automake@gnu.org
mailing list for the automake project.
Re: libraries within libraries
- From: "Steve M. Robbins" <steven dot robbins at videotron dot ca>
- To: Marco Correia <mvc at netcabo dot pt>
- Cc: automake at gnu dot org
- Date: Tue, 29 Apr 2003 16:19:10 -0400
- Subject: Re: libraries within libraries
- References: <200304292010.01912.mvc@netcabo.pt>
On Tue, Apr 29, 2003 at 08:10:01PM +0000, Marco Correia wrote:
> Now the problem is whenever I try to link libsrc.a with an example source that
> uses the library
>
> g++ -g -O2 -o example1 example1.o ../library/libsrc.a
>
> I get lots of undefined references to classes in the library in the link
> phase.
>
> But if I build libsrc as a shared library I have no problems of any sort.
>
> What could be the cause of this?
I don't know, but:
Is it possible that some of the compiled .o files comprising libsrc.a
depend on others? It is important to get the order right for static
libraries. For example, if libX requires symbols in libY, you have to
link in the correct order: "cc foo.o -lX -lY", not "cc foo.o -lY -lX".
However, on some systems (e.g. linux) when libX and libY are shared,
this no longer matters. At run time, all the symbols are always
available.
Something similar might be going on in the line that builds libsrc.a
since it is being built from other "noinst" libraries.
-S