[Top][All Lists]

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

Re: How to use ld options correctly for --whole-archive in automake and

From: Thomas Jahns
Subject: Re: How to use ld options correctly for --whole-archive in automake and libtool
Date: Fri, 06 Mar 2015 09:46:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.5.0

On 03/05/15 18:28, Andy Falanga (afalanga) wrote:
-----Original Message-----
From: Thomas Jahns [mailto:address@hidden
Sent: Wednesday, March 04, 2015 5:45 PM
To: Andy Falanga (afalanga)
Cc: address@hidden
Subject: Re: How to use ld options correctly for --whole-archive in
automake and libtool

This is, from my point of view not so much an automake issue but a
libtool problem: libtool for some reason I don't know decided to make -
Wl, be the prefix for options to be passed to libtool when it's also
the prefix for gcc and various other compilers (which serve as link
editor frontend) for options to pass to the linker and then decides
later to pass this on to the linker program (CC/CXX/whatever). These
"options" are then re-ordered with respect to non-options (like
your .a files) which makes it difficult to pass them in the correct

For this very reason, I decided to subscribe to libtool's mailing list
also and ask the same question there.  As yet, however, I've received no
responses.  Since the tools worked together, it still made sense to ask
here as well.

position. You might be able to work around this with judicious use of
extra -Wl, prefixes like this:

sata_la_LIBADD = -Wl,-Wl,,--whole-archive,../Shared/HwMgmt/.libs/
whole-archive -lz -lrt

A very interesting suggestion.  I shall have to try this.  I found
something similar, after the many, many searches I've done with
Google.  It didn't have this many uses of "-Wl," though so that is
quite interesting.

Also it should be noted that you would need to make the files in libhwmgmt.a be PIC objects instead of non-PIC as libtool will create by default.

This is a good question.  I have been asking myself the same thing.
Using these tools opens up a newer deployment method than we've used
to this point.  I do still have to answer a question of how I shall
statically link with other libraries, most notably Boost.  The systems
we deploy to will either not have these libraries altogether or they
have such woefully out of date versions that statically linking with
these other libraries is the only option.  How would I ensure I statically
link with these libraries using the automake process?

That's not something you want to fix from within automake but rather specify something like LIBS="-Bstatic -lboost -Bdynamic" at configure time since it addressed a specific issue of the build you intend to do and not your package itself.

But you can still link dynamically to different library versions than those installed on the system by making use of -Wl,-rpath on Linux. I haven't gone through the process for plugins myself so I might be missing something that forces inclusion of the objects.

Regards, Thomas

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

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