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.
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?
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.
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.
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).
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?
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.
(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.
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.
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.
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.
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.