Hello Simon, Apologies for the delay.
* Simon Richter wrote on Tue, Jul 11, 2006 at 03:57:36PM CEST: > > a lot of projects that are just starting out still make quite a lot of > changes to their library ABI, so it does not make full sense to build a > shared library right away, but sometimes it is still necessary to have > PIC code around, for example when building a plugin to be dlopen()ed by > some program. If said library and the plugin code also live in separate > packages, you have a bit of a problem with current libtool. For one, using -avoid-version would be a good idea in this case. > The idea at this point would be to add another switch "-unstable-abi", > which would make libtool generate an archive instead of a shared library > (as it would for a convenience library), but also install both variants > (perhaps as libfoo.a and libfoo_pic.a). Shared object links against that > library would then simply include the ..._pic.a file on the linker > command line. Well, but that way you break the dependency algorithm, at least the way it works currently: you run into possibly duplicated symbols. This is bad when it breaks with a link failure, but it's worse when all you get is a silent failure: For example, you may now have two instances of some file-scope static counter... I don't see an easy portable solution to the problem. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool