* Tim Mooney wrote on Mon, Jul 03, 2006 at 11:17:03PM CEST: > So to address this, libtool would need to > > - know how the platform behaves regarding shared library dependencies > - in the case of static libraries, continue doing what it's already doing > - for shared libraries on platforms where the linker follows library > dependencies > - when creating a shared library, make sure that it's dependent > libraries are recorded (however that's done for a particular > platform, probably just linking) by the library when it's created. > - when linking against a shared library of this type, detect which > libraries are recorded as dependant for the shared library and > leave those out of the list of dependency_libs for the shared > library. > > Is that about it?
No. It's much more complicated. If you allow the concept of indirect dependencies, - you must make sure that uninstalled libraries which happen to be indirect dependencies, are properly linked against (instead of an earlier installed version) when executing uninstalled programs, - that upon installation, libraries and programs properly do not contain any build-tree paths any more, - match that with an aim to get -fast-install and -no-fast-install working properly, and with relink-upon-execution and relink-upon- installation, - the many different semantics for hardcoding make this even "more interesting" ... for example, one we would need the information whether the linker and/or the runtime loader respect runpaths (and in which priority) for indirect dependencies, and whether with priority over the shlibpath variable. This is trickier than you think: some GNU/Linux distributions even install GNU binutils with a different default... Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
