Hello, * Bob Friesenhahn wrote on Wed, Sep 10, 2008 at 06:26:34PM CEST: > > Multilib support via libtool has been on the wish list for quite a while > but implementing it is either a Big Job for libtool, or for the build > environments which drive it. It seems to me that if libtool supports the > ability to build/install for an "offset" directory that the rest of the > responsibility can fall into the hands of autoconf and automake. There are several issues mentioned here. Among them: - using an "offset" directory. Sounds a bit like $ORIGIN or other relocatable technique to me. For such functionality, libtool would need quite a few adjustments. Also, these relocation things are not portable, so we need to be able to degrade gracefully on less able systems/linkers. - computing the default libdir. I would be glad to see all autotools, including libtool and gnulib's lib-link, use consistent default values. The code should ideally not be duplicated though, which is quite certain to prevent consistency. Even more ideally, it should not be duplicated among autotools and GCC either. For other compilers, I don't currently see much choice. FWIW, I don't see any of the current proposals in this thread as sufficient yet. IIRC then only recent releases of GCC provided the needed bits, and I'm not convinced it provides enough information even now. - several problem within libtool: current libtool simply compares library directories by string comparison, without `../' and symlink name removal. A general solution to this is rather hard, if not impossible to do without some assumptions. I'm not saying this must be solved fully, but libtool should work well with a new default libdir computation. For example, it should not add a run path just because the user specified /usr/lib/../lib64 as installation directory for a library rather than /usr/lib64. - current libtool picks a .la file when it finds one, irrespective of whether it is for the correct multilib flavor or the wrong one. This leads to the need to be very careful to never introduce the wrong directory into its search path. One way out would be to encode the multilibness in the .la file. Ugly, because it would be nice not to have to make assumptions about the multilib flavors. > There > would need to be a configure framework which knows about the "standard" > multilib conventions for each target and a build framework which builds > all of them (or just the ones desired). Libtool is already complex enough > so I think that most of the responsibility should be outside of libtool. > Libtool needs to know how to store multilib objects/libraries in the > build tree (perhaps via a user provided 'tag') , and how to install the > correct ones when requested. Agreed: it would be good if this knowledge were not replicated inside libtool's primary sources, as it certainly is not a feature that is needed solely when you create libraries. This isn't much of a question of how complex libtool is already, but of code orthogonality. To summarize, I don't think all these issues need to be addressed, or addressed at the same time, but if non-canonicalized paths are to be the default then libtool needs a bit of help at least. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
