> -----Original Message----- > From: Thomas Jahns [mailto:ja...@dkrz.de] > Sent: Wednesday, March 04, 2015 5:45 PM > To: Andy Falanga (afalanga) > Cc: automake@gnu.org > 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. > But what exactly is the problem with using e.g. ../Shared/HwMgmt/ > libhwmgmt.la? That sata.so will then require libhwmgmt.so? libtool > should be able to set sata.so's rpath such that libhwmgmt.so will be > found at runtime. > 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?