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

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

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

           Summary: [4.6 Regression] libgfortran relocated install fails
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jsm28@gcc.gnu.org


Installing Fortran-enabled GCC to a path other than the configured prefix, via
"make install prefix=/whatever" (which is supposed to be supported according to
the GNU Coding Standards) now fails.  Probably caused by the the libquadmath
changes; it certainly worked last month.  You get errors of the form:

 /usr/local/tools/gcc-4.3.3/bin/bash ./libtool   --mode=install
/usr/local/tools/gcc-4.3.3/bin/install -c   libgfortran.la
'/scratch/gcc/nightly-2010-11-22-mainline/i686-pc-linux-gnu/install/lib/../lib64'
libtool: install: error: cannot install `libgfortran.la' to a directory not
ending in /opt/codesourcery/lib/../lib64
make[8]: *** [install-toolexeclibLTLIBRARIES] Error 1

This was known to be broken for Java - see
http://gcc.gnu.org/ml/gcc/2006-12/msg00363.html - but the Fortran breakage is a
regression.

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0

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

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-07 11:09:26 UTC ---
Do we really need to support it?  DESTDIR just works, and when install
prefix=/whatever doesn't work already for Java, why would anyone expect it
works for Fortran?

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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-07 13:25:18 UTC ---
On Tue, 7 Dec 2010, jakub at gcc dot gnu.org wrote:

> Do we really need to support it?  DESTDIR just works, and when install
> prefix=/whatever doesn't work already for Java, why would anyone expect it
> works for Fortran?

I believe there are MinGW cases that cannot effectively be done using 
DESTDIR.  It would be expected to work with Fortran because it always has 
worked with Fortran before; Java was the odd one out.  And of course it is 
a standard GCS facility.

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

[rwild at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

Ralf Wildenhues <rwild at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwild at gcc dot gnu.org

--- Comment #3 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2010-12-13 16:57:27 UTC ---
So is this only about the MinGW case?  Because there, we should just fix
libtool to not ever relink.

The more general issue described in comment #1 is a long-standing limitation of
libtool.

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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-12-13 18:39:47 UTC ---
On Mon, 13 Dec 2010, rwild at gcc dot gnu.org wrote:

> So is this only about the MinGW case?  Because there, we should just fix
> libtool to not ever relink.

No, it's about the general issue; MinGW is simply one of the cases where 
the "make install prefix=" semantics are preferred to DESTDIR (but in 
general when dealing with lots of versions of lots of software each may 
have cases where the other doesn't work).

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

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.20 21:54:49
                 CC|                            |aoliva at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #5 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-20 21:54:49 UTC ---
I'm tempted to mark this as WONTFIX.  This is a libtool requirement with good
reasons behind it, and the long-known work-around is quite easy: use as the new
prefix a directory ending with the old prefix.  Any objections?

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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-24 23:29:27 UTC ---
That would not be an appropriate use of WONTFIX; WONTFIX is for cases such 
as bugs in a target that has been removed.  It's a clear bug in libtool; 
SUSPENDED might be more appropriate for things waiting on a libtool fix.

I would note incidentally a suggestion (comment #3) to work around the 
general libtool bug on MinGW by stopping it relinking on MinGW.  I don't 
believe there's any good reason for it to be relinking for GCC builds to 
ELF targets either, so perhaps stopping relinking there would help avoid 
this problem in many more cases.

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

[rwild at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #7 from Ralf Wildenhues <rwild at gcc dot gnu.org> 2011-01-25 06:40:20 UTC ---
(In reply to comment #6)
> I would note incidentally a suggestion (comment #3) to work around the 
> general libtool bug on MinGW by stopping it relinking on MinGW.  I don't 
> believe there's any good reason for it to be relinking for GCC builds to 
> ELF targets either, so perhaps stopping relinking there would help avoid 
> this problem in many more cases.

But there is a good reason to relink on ELF: uninstalled libraries and
executables get DT_RPATH entries against uninstalled libraries they depend on,
so that uninstalled programs can be executed in a test suite before installing
the libraries they depend on.  Removing (or replacing) those DT_RPATH entries
is the point of relinking.  That GCC takes care of the uninstalled paths in
some other way as well is something libtool cannot know.

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

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-01-25 16:55:18 UTC ---
On Tue, 25 Jan 2011, rwild at gcc dot gnu.org wrote:

> But there is a good reason to relink on ELF: uninstalled libraries and
> executables get DT_RPATH entries against uninstalled libraries they depend on,
> so that uninstalled programs can be executed in a test suite before installing
> the libraries they depend on.  Removing (or replacing) those DT_RPATH entries
> is the point of relinking.  That GCC takes care of the uninstalled paths in
> some other way as well is something libtool cannot know.

Of course it can know - it just needs an appropriate way for GCC to inform 
libtool that the GCC testsuites take care of library paths.

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

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-27 03:22:30 UTC ---
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. 
So if WONTFIX is not appropriate, INVALID it is.

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

[joseph at codesourcery dot com]

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.

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

[aoliva at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607

--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2011-01-28 07:38:06 UTC ---
Yeah, relinking, not prelinking, sorry.

I guess something along the lines of make_relative_prefix might work, if a
twisted maze of soft links doesn't make it unworkable.  IIRC that's why libtool
decided to support DESTDIR but not arbitrary prefix changes.

In order to avoid relinking, you can configure with --enable-fast-install, but
I haven't checked this will work around the install-time complaint, and I'm
concerned that, at least on some systems, it might cause old preinstalled
dependency libraries to be used instead of just-built ones, in spite of GCC's
setting of SHLIB_PATH or equivalent.  I guess it may be worth a shot if you
want to operate outside libtool's (current) specs.

All that said, this is probably not the right forum to discuss bugs or suggest
improvements for libtool.  Heck, I haven't even been involved with libtool for
years, so I might as well back away slowly ;-)  IMHO, odds are better of having
it resolved for good (improved or rejected) if you take it upstream.  Now, if
you'd like to reopen this once it's in libtool's bug database, with a pointer
to it in “See Also”, just so that it's tracked in GCC's bug database, no
objections from me.