This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

3.1 PATCH: Avoid automounter pathnames in config-ml.in


For a long time, when running the libstdc++ testsuite with -m64 on
sparc-sun-solaris2.8, all tests failed for me:

	http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg01128.html

libstdc++.log shows that the tests fail to link with `-lstdc++ not found'.
This happened since during the configure run for the sparcv9 libstdc++
multilib the correct multilib flag (-m64) was appended to glibcpp_CXX, but
the -L flag in that variable remained at it's default, i.e. pointing to the
32-bit default multilib, which the linker ignored during the -m64 link:
i.e. the sparcv9 libstdc++-v3 Makefile glibcpp_CXX contained

	-L$blddir/sparc-sun-solaris2.8/libstdc++-v3/src
	-L$blddir/sparc-sun-solaris2.8/libstdc++-v3/src/.libs
	-m64

instead of the correct

	-L$blddir/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src
	-L$blddir/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/.libs
	-m64

The same (incorrect) values are substituted in testsuite_flags, and the
testsuite uses the output of testsuite_flags --build-cxx to determine the
compiler to test.

This substitution of a non-default multilib in -L flags should be performed
by the toplevel config-ml.in, but in my case failed because of an bad
interaction of the amd automounter and /bin/sh's built-in pwd:

config-ml.in is to substitute the output of pwd in
$blddir/sparc-sun-solaris2.8 with it's corresponding multilib subdir,
i.e. $blddir/sparc-sun-solaris2.8.  In my case, the Makefile had a logical
pathname for $blddir (i.e. /vol/gcc/obj/gcc-3.1), but /bin/sh's pwd returns
the underlying physical pathname instead (something like
/amnt/figaro/volumes/obj-gcc/gcc/obj.sol2/gcc-3.1).  Obviously they don't
match and the substitution does not occur, leading to the observed broken
testsuite results.  Once the problem had been analysed, the fix is simple:
allow for the use of a automounter-aware pwd command instead of the
hardcoded pwd, just as was done e.g. in the thread starting at

	http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01254.html

and finally resolved by

	http://gcc.gnu.org/ml/gcc-patches/2001-05/msg01827.html

The trivial patch below does this and allowed me to get good -m64 libstdc++
testsuite results:

	http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00041.html

I fear I'll really have to check the whole tree for dubious uses of that
`cd $dir && pwd` construct and apply corresponding patches ;-(

Fully bootstrapped without regressions on sparc-sun-solaris2.8.  Ok for
branch and trunk?

	Rainer


Thu May  2 21:31:04 2002  Rainer Orth  <ro@TechFak.Uni-Bielefeld.DE>

	* config-ml.in: Allow for PWDCMD to determine ML_POPDIR.

Index: config-ml.in
===================================================================
RCS file: /cvs/gcc/gcc/config-ml.in,v
retrieving revision 1.19
diff -u -p -r1.19 config-ml.in
--- config-ml.in	13 Jun 2001 02:12:07 -0000	1.19
+++ config-ml.in	2 May 2002 20:13:19 -0000
@@ -756,7 +756,7 @@ if [ -n "${multidirs}" ] && [ -z "${ml_n
     esac
 
     # FIXME: POPDIR=${PWD=`pwd`} doesn't work here.
-    ML_POPDIR=`pwd`
+    ML_POPDIR=`${PWDCMD-pwd}`
     cd ${ml_dir}/${ml_libdir}
 
     if [ -f ${ml_newsrcdir}/configure ]; then


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