This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
staging headers fix (was Re: libstdc++ problem)
- To: Gabriel Dos Reis <Gabriel dot Dos-Reis at cmla dot ens-cachan dot fr>
- Subject: staging headers fix (was Re: libstdc++ problem)
- From: Phil Edwards <pedwards at disaster dot jaj dot com>
- Date: Sat, 14 Jul 2001 20:30:33 -0400
- Cc: Anthony Green <green at cygnus dot com>, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org, neil at daikokuya dot demon dot co dot uk
- References: <200107141315.GAA07484@makita.cygnus.com> <flae27jzcb.fsf@sel.cmla.ens-cachan.fr>
On Sat, Jul 14, 2001 at 05:37:56PM +0200, Gabriel Dos Reis wrote:
> Anthony Green <green@cygnus.com> writes:
>
> | This change...
[staging headers patch]
> | Introduced a configury problem. libstdc++-v3 fails to build if you
> | configure with a relative path to the source, like
> | ../gcc/configure
> |
> | The symlinks should be created with absolute paths.
They are... at least for Stephen, Loren, Benjamin, and me. All of the source
headers in include/Makefile.am are named beginning with ${glibcpp_srcdir},
which is set like this in acinclude.m4's GLIBCPP_EXPORT_INSTALL_INFO:
# Export build and source directories.
# These need to be absolute paths, yet at the same time need to
# canonicalize only relative paths, because then amd will not unmount
# drives. Thus the use of PWDCMD: set it to 'pawd' or 'amq -w' if using amd.
glibcpp_builddir=`pwd`
case $srcdir in
[\\/$]* | ?:[\\/]*) glibcpp_srcdir=${srcdir} ;;
*) glibcpp_srcdir=`cd "$srcdir" && ${PWDCMD-pwd} || echo "$srcdir"` ;;
esac
Normally I build with absolute paths to configure, but I just tested a
relative-path configure, and while 'srcdir' and whatnot are coming out
relative in include/Makefile, glibcpp_srcdir is absolute, and the symlinks
are still absolute.
We need to figure out why your paths aren't being canonicalized. The bits
I just quoted above have been in place for a while. Anyone using an
automounter? I can't reproduce this problem locally.
Short term... sigh. That patch fixes so much stuff I'd hate to revert
the whole thing. Why don't we just force the headers to be copied rather
than symlinked? It's only a single line (patch below), it preserves all
the other semantics we've been trying to achieve, it lets the autobuilders
succeed, and it lets other people depending on this patch go forward.
Everybody wins. (At least until Monday when we try to find a real solution.)
This is just a temporary patch; I still think we want symlinks by default,
so that's why I didn't change all the @LN_S@ invocations.
Tested on x86/linux with a relative-pathed configure. Can somebody else
test this before checkin? There's no point doing a temporary slapdash
fix if it doesn't even help. :-)
Phil
Index: configure.in
===================================================================
RCS file: /home/pme/Repositories/GCC/gcc/libstdc++-v3/configure.in,v
retrieving revision 1.67
diff -u -3 -r1.67 configure.in
--- configure.in 2001/07/13 16:47:55 1.67
+++ configure.in 2001/07/15 00:12:58
@@ -38,6 +38,7 @@
# Will set LN_S to either 'ln -s' or 'ln'. With autoconf 2.50+, can also
# be 'cp -p' if linking isn't available.
+ac_cv_prog_LN_S='cp -p'
AC_PROG_LN_S
# We use these options to decide which functions to include.