This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

staging headers fix (was Re: libstdc++ problem)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]