[Top][All Lists]

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

LDADD and linker options like --whole-archive

From: Stefan Puiu
Subject: LDADD and linker options like --whole-archive
Date: Wed, 19 Apr 2006 17:23:04 +0300


I was considering to file this as a bug report, but I thought I'd
first check on the list first. Sorry if this was already brought up
(there's also a bug report which is somewhat similar to my problem -
automake PR number 55).

So, my problem is that for some reason in our projects some libraries
*have* to be linked in using a --whole-archive/--no-whole-archive wrap
around them. I also use --start-group/--end-group when I have to add a
long list of libraries (dozens) and I don't want to waste time trying
to put them in the right order.

Now, how would we add those libraries to the linker options in my files?

Option 1: add the directories to <binary>_LDFLAGS (-L<dir1> ...) and
then the libraries with -l<lib1> ..., wrapped around with
--whole-archive in <binary_LDADD>. However, this doesn't work, since
you can't add linker options in <binary_LDADD>:

linker flags such as `-Wl,--whole-archive' belong in `<binary>_LDFLAGS

is the error message printed by automake when you try to do that. The
same happens with --start-group/--end-group. This is also documented
in the automake manual I have.

Option 2: OK, so what if we try to add the libraries in
<binary>_LDFLAGS? Well, that one doesn't work either. Why? Well, the
linker command generated is like this:

$(CXXLINK) $(binary_LDFLAGS) $(binary_OBJECTS) $(binary_LDADD) $(LIBS)

Can you spot the problem? Yes, _LDFLAGS comes *before* _OBJECTS; due
to the way the GNU linker (and other UNIX linkers, by tradition)
works, the order of libraries and objects matters. So any symbols
referenced in <binary>_OBJECTS, but not in <binary_LIBRARIES> will
show up as unresolved. Oops.

It won't work if you try to change <binary>_LINK, unless you have no
objects to link to the binary (which is true for some of the targets
we use - they just link libraries into a binary, as funny as that may
seem). Because <binary>_LINK is the command that gets passed the list
of objects for the binary, so the objects still end up at the end of
the command. Oops again.

So the only option is to write your own <binary> target that does
exactly what you want. But then why use automake in the first place?

Am I missing something, or is this setup as bad as it seems? I think
in most cases it's likely that <binary>_OBJECTS will use an object in
one of the linked in libraries that wasn't used in libraries linked
before. If you don't need any linker options, then _LDADD comes to the
rescue. But otherwise? How would that be solved?

Wouldn't it make sense to just raise the limitation on _LDADD? That
would fix my problem. I think the LDADD limitation (documented in the
automake manual here:
is simply overlooking sane linker options like --start-group, which
make sense to be used in Makefile.ams.

I'm using automake 1.9.5, and GNU make 3.80.


reply via email to

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