automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nesting and final linking ?


From: Ralf Wildenhues
Subject: Re: Nesting and final linking ?
Date: Thu, 7 Aug 2008 20:33:27 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi Nick,

* nickthefarrow wrote on Thu, Aug 07, 2008 at 02:27:03PM CEST:
> Ralf,
> 
> Spot on :)

I wish all reports were this straightforward.  ;-)

> bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2 --tag=CXX  -o

This is weird: why is there a --tag=CXX so late in the game?
It should appear before --mode.  Did you perchance put it manually in
Makefile.am?  If yes, then you need to move it to a *_LIBTOOLFLAGS
variable or override the LIBTOOL variable.  But I'd advise against
either unless you are specifically working around something.

If you would like to get libtool to use the C++ compiler (and settings)
for linking, then the end of this manual node contains a hint:
<http://www.gnu.org/software/automake/manual/html_node/Libtool-Convenience-Libraries.html>.

> libwhite.la -rpath /usr/local/lib  src/utils/libutils.la
> src/common/libcommon.la src/libsrc.la src/containers/libcontainers.la
> src/FileIO/libfileio.la src/network/libnetwork.la src/parsers/libparsers.la
> src/servers/libservers.la src/stacks/libstacks.la
> 
> This bit looks fine, all the sub libs components are mentioned here (above)

> gcc -shared  -Wl,--whole-archive src/common/.libs/libcommon.a
> src/.libs/libsrc.a src/containers/.libs/libcontainers.a
> -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/nick/libwhite/src/utils/.libs
> -Wl,--rpath -Wl,/home/nick/libwhite/src/FileIO/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/network/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/parsers/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/servers/.libs -Wl,--rpath
> -Wl,/home/nick/libwhite/src/stacks/.libs -Wl,--rpath -Wl,/usr/local/lib
> src/utils/.libs/libutils.so src/FileIO/.libs/libfileio.so
> src/network/.libs/libnetwork.so src/parsers/.libs/libparsers.so
> src/servers/.libs/libservers.so src/stacks/.libs/libstacks.so  -Wl,-soname
> -Wl,libwhite.so.0 -o .libs/libwhite.so.0.0.0

This bit of output indicates that these are convenience archives (i.e.,
noinst_LTLIBRARIES):
  src/common/libcommon.la src/libsrc.la src/containers/libcontainers.la

while these are real shared, to-be-installed, libraries (i.e.,
lib_LTLIBRARIES or similar):
  src/utils/libutils.la src/FileIO/libfileio.la
  src/network/libnetwork.la src/parsers/libparsers.la
  src/servers/libservers.la src/stacks/libstacks.la

That means, that the first three will end up as a whole being part of
libwhite, while the last six will be independent entities, upon which
libwhite will depend.  However, libwhite will not contain any code of
them directly.  This makes sense: that way, each function is contained
at most once in the set of installed libraries.

If that is not what you wanted, then you should consider making the
other libraries into convenience archives.

If however that is what you wanted, then I suggest using a bit more
specific names for the libraries.  libutils is quite generic and likely
to interfere with somebody else who had the same naming idea.  Keep in
mind that every library you install effectively lives in a global
namespace, one for the library name (and soname), and also their
functions live in a global namespace, and hopefully are part of a
defined and stable API.  (Consider hiding functions you don't want to be
used outside the library; at least for systems that provide hiding.)

> This again looks ok (above)

> ar cru .libs/libwhite.a  
> .libs/libwhite.lax/libcommon.a/libcommon_la-packetbuffer.o
[...]
> .libs/libwhite.lax/libcommon.a/libcommon_la-ITokenizer.o 
> .libs/libwhite.lax/libsrc.a/libsrc_la-IDebug.o
> .libs/libwhite.lax/libsrc.a/libsrc_la-IObject.o 
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IFileTree.o
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IVariant.o
> .libs/libwhite.lax/libcontainers.a/libcontainers_la-IMIMETypes.o

> The final library only consists of libsrc, libcommon, libcontainers and not
> the others libstacks etc, and it looks like libcommon is partial, it should
> consist of 39 objects I dont really know what script its running here
> (ltmain.sh?) or why is missing the rest.

The script that creates libraries is 'libtool', it is created from some
variables set by configure, combined with the ltmain.sh file.

> The only thing that comes to mind is running out of environment space?

That would be a bit surprising, your example doesn't look particularly
big (there are libraries consisting of dozens of convenience archives,
and comprising hundreds of objects), and libtool really aims at working
around all those system limitations.

Since the part about the missing libs has already been addressed, the
only remaining bit is the missing objects from libcommon.  Can you post
the output of the following:

  make >/dev/null    # this output is not interesting
  ./libtool --mode=clean rm -f src/common/libcommon.la libwhite.la
  make

Also, please post the output of
  ./libtool --tag=CXX --config

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]