Hi Marc, thanks a lot for your assistance. Now I think I understand the point.
It seems like a good solution for the future, however, I don't have the time to try this right now, and in the short term it doesn't seem to bring significant improvements, besides allowing me to get rid of --whole-archive/--no-whole-archive. There's also one catch - some of the libraries need to register in some binaries, while not in others - let's say you have libfoo.a which has SomeRegisteringComponent.o and SomeOtherUtilities.o. In one binary I want to use the registering component, which will require the library to be linked without leaving anything out. However, some binaries will only need SomeOtherUtilities.o, so then I can just leave libfoo.a out of the whole-archive list when building them. Our code is proprietary and closed source, no chance of seeing it on the web, unfortunately. Also, I think what we do is standardize our developing environment on something that one Linux vendor provides, because we have some sort of support contract with them (as far as I understand). Most of the stuff we use is 2 years old - gcc (3.3), GNU make, autotools etc. Switching to unofficially patched CVS versions of the autotools would probably not be contemplated by people making this kind of decisions here. Stefan. On 4/20/06, Marc Alff <[EMAIL PROTECTED]> wrote: > Let me try to explain how the whole thing would work in your case : > Assumption is that today, you have something like this > [...] > Also, keep in mind this enhancement is not part of the official automake > release yet, > but I hope to convince Alexandre (and Ralf for a change in libtool) at > some point, > and seeing if it solves your problem will work towards that :) > > Let me know how I can assist you with all this. > If your code is public and available on the web, I can look at it and at > the Makefile.am changes. > > Hope this helps, > Marc Alff. > > >
