http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607
--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-27 17:47:12 UTC --- On Thu, 27 Jan 2011, aoliva at gcc dot gnu.org wrote: > This could bring an improvement for a few platforms, but it wouldn't solve the > problme in general. On platforms that don't support overriding e.g. DT_RPATH > with e.g. LD_LIBRARY_PATH, the right thing to do is still to require > prelinking. Libtool, in an effort to offer a standard interface, has decided > to impose the requirement that the install-time libdir must end with the > libdir > specified at build time. This is not a bug, it's a correct design decision. I don't see how prelinking (relinking?) relates to the relation between two libdir values. What platform's shared library peculiarities allow installation where one libdir is a prefix of the other but not more general relations like those allowed by make_relative_prefix? As far as I can see, it should be a straightforward generalization of any logic supporting adding a prefix to libdir to support also removing some initial directory segments first. In fact, if you're relinking I don't see the need to care about the configure-time directories at all. At build time, link only for the build-tree paths, if any paths need hardcoding anywhere at all; at install time, link only for the paths determined by the makefile variables at install time; at both times, disregard the paths passed to configure except insofar as they determine the makefile variables at install time. Support for removing initial segments when installing would probably be more of a straightforward change, however, but in any case it seems to be a libtool bug to me.
