[Bug libfortran/46607] [4.6 Regression] libgfortran relocated install fails
joseph at codesourcery dot com
gcc-bugzilla@gcc.gnu.org
Thu Jan 27 18:06:00 GMT 2011
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.
More information about the Gcc-bugs
mailing list