[Bug libfortran/46607] [4.6 Regression] libgfortran relocated install fails

["joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

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.