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

[Thomas Jahns]

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/
> > libhwmgmt.a,../Shared/Misc/.libs/libmisc.a,.libs/libsata.a,-Wl,,--no-
> > 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

smime.p7s
Description: S/MIME Cryptographic Signature