On Thu, Mar 5, 2015 at 6:28 PM, Andy Falanga (afalanga) <afala...@micron.com> wrote: >> -----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.
I would also use $(top_builddir) instead of relative path. It could help when building in another directory than the source one (like with make distcheck) Vincent Torri > > 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? > >
