From phil at jaj.com Fri Jul 11 02:14:51 2003 From: phil at jaj.com (Phil Edwards) Date: Thu, 10 Jul 2003 22:14:51 -0400 Subject: Updating top-level files for automake Message-ID: <20030711021451.GA7995@disaster.jaj.com> As part of the transition, libstdc++ will be going to automake 1.7, for its features and bugfixes. However, trying to configure using this version results in problems, because $srcdir/missing is too old. I updated missing, install-sh, and mkinstalldirs to the versions which aclocal/automake would install in a new project. There do not appear to be any backward incompatabilities, so directories which have not yet converted to newer autoconfs, and/or are not using automake at all, should have no difficulties. Nevertheless, please look these diffs over. I'll continue to use them in my local tree as I wrestle with autoconf. If you agree that these patches are safe, I'll send them to gcc-patches for a wider audience and discussion. (I tend to think of these files like config.{guess,sub}, where they can simply be updated as needed, but...) Index: install-sh =================================================================== RCS file: /home/pme/Repositories/GCC/gcc/install-sh,v retrieving revision 1.4 diff -u -3 -r1.4 install-sh --- install-sh 25 Jan 2002 23:42:28 -0000 1.4 +++ install-sh 10 Jul 2003 23:24:04 -0000 @@ -1,19 +1,37 @@ #!/bin/sh # # install - install a program, script, or datafile -# This comes from X11R5 (mit/util/scripts/install.sh). # -# Copyright 1991 by the Massachusetts Institute of Technology +# This originates from X11R5 (mit/util/scripts/install.sh), which was +# later released in X11R6 (xc/config/util/install.sh) with the +# following copyright and license. # -# Permission to use, copy, modify, distribute, and sell this software and its -# documentation for any purpose is hereby granted without fee, provided that -# the above copyright notice appear in all copies and that both that -# copyright notice and this permission notice appear in supporting -# documentation, and that the name of M.I.T. not be used in advertising or -# publicity pertaining to distribution of the software without specific, -# written prior permission. M.I.T. makes no representations about the -# suitability of this software for any purpose. It is provided "as is" -# without express or implied warranty. +# Copyright (C) 1994 X Consortium +# +# Permission is hereby granted, free of charge, to any person obtaining a copy +# of this software and associated documentation files (the "Software"), to +# deal in the Software without restriction, including without limitation the +# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or +# sell copies of the Software, and to permit persons to whom the Software is +# furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC- +# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. +# +# Except as contained in this notice, the name of the X Consortium shall not +# be used in advertising or otherwise to promote the sale, use or other deal- +# ings in this Software without prior written authorization from the X Consor- +# tium. +# +# +# FSF changes to this file are in the public domain. # # Calling this script install-sh is preferred over install.sh, to prevent # `make' implicit rules from creating a file called install from it @@ -56,7 +74,7 @@ while [ x"$1" != x ]; do case $1 in - -c) instcmd="$cpprog" + -c) instcmd=$cpprog shift continue;; @@ -79,7 +97,7 @@ shift continue;; - -s) stripcmd="$stripprog" + -s) stripcmd=$stripprog shift continue;; @@ -106,128 +124,132 @@ if [ x"$src" = x ] then - echo "install: no input file specified" + echo "$0: no input file specified" >&2 exit 1 else - true + : fi if [ x"$dir_arg" != x ]; then dst=$src src="" - - if [ -d $dst ]; then + + if [ -d "$dst" ]; then instcmd=: chmodcmd="" else - instcmd=mkdir + instcmd=$mkdirprog fi else # Waiting for this to be detected by the "$instcmd $src $dsttmp" command -# might cause directories to be created, which would be especially bad +# might cause directories to be created, which would be especially bad # if $src (and thus $dsttmp) contains '*'. - if [ -f $src -o -d $src ] + if [ -f "$src" ] || [ -d "$src" ] then - true + : else - echo "install: $src does not exist" + echo "$0: $src does not exist" >&2 exit 1 fi - + if [ x"$dst" = x ] then - echo "install: no destination specified" + echo "$0: no destination specified" >&2 exit 1 else - true + : fi # If destination is a directory, append the input filename; if your system # does not like double slashes in filenames, you may need to add some logic - if [ -d $dst ] + if [ -d "$dst" ] then - dst="$dst"/`basename $src` + dst=$dst/`basename "$src"` else - true + : fi fi ## this sed command emulates the dirname command -dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'` +dstdir=`echo "$dst" | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'` # Make sure that the destination directory exists. # this part is taken from Noah Friedman's mkinstalldirs script # Skip lots of stat calls in the usual case. if [ ! -d "$dstdir" ]; then -defaultIFS=' -' -IFS="${IFS-${defaultIFS}}" +defaultIFS=' + ' +IFS="${IFS-$defaultIFS}" -oIFS="${IFS}" +oIFS=$IFS # Some sh's can't handle IFS=/ for some reason. IFS='%' -set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'` -IFS="${oIFS}" +set - `echo "$dstdir" | sed -e 's@/@%@g' -e 's@^%@/@'` +IFS=$oIFS pathcomp='' while [ $# -ne 0 ] ; do - pathcomp="${pathcomp}${1}" + pathcomp=$pathcomp$1 shift - if [ ! -d "${pathcomp}" ] ; + if [ ! -d "$pathcomp" ] ; then - $mkdirprog "${pathcomp}" + $mkdirprog "$pathcomp" else - true + : fi - pathcomp="${pathcomp}/" + pathcomp=$pathcomp/ done fi if [ x"$dir_arg" != x ] then - $doit $instcmd $dst && + $doit $instcmd "$dst" && - if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi && - if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi && - if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi && - if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi + if [ x"$chowncmd" != x ]; then $doit $chowncmd "$dst"; else : ; fi && + if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd "$dst"; else : ; fi && + if [ x"$stripcmd" != x ]; then $doit $stripcmd "$dst"; else : ; fi && + if [ x"$chmodcmd" != x ]; then $doit $chmodcmd "$dst"; else : ; fi else # If we're going to rename the final executable, determine the name now. - if [ x"$transformarg" = x ] + if [ x"$transformarg" = x ] then - dstfile=`basename $dst` + dstfile=`basename "$dst"` else - dstfile=`basename $dst $transformbasename | + dstfile=`basename "$dst" $transformbasename | sed $transformarg`$transformbasename fi # don't allow the sed command to completely eliminate the filename - if [ x"$dstfile" = x ] + if [ x"$dstfile" = x ] then - dstfile=`basename $dst` + dstfile=`basename "$dst"` else - true + : fi -# Make a temp file name in the proper directory. +# Make a couple of temp file names in the proper directory. - dsttmp=$dstdir/_inst.$$_ + dsttmp=$dstdir/#inst.$$# + rmtmp=$dstdir/#rm.$$# -# Move or copy the file name to the temp name +# Trap to clean up temp files at exit. - $doit $instcmd $src $dsttmp && + trap 'status=$?; rm -f "$dsttmp" "$rmtmp" && exit $status' 0 + trap '(exit $?); exit' 1 2 13 15 + +# Move or copy the file name to the temp name - trap "rm -f ${dsttmp}" 0 && + $doit $instcmd "$src" "$dsttmp" && # and set any options; do chmod last to preserve setuid bits @@ -235,17 +257,38 @@ # ignore errors from any of these, just make sure not to ignore # errors from the above "$doit $instcmd $src $dsttmp" command. - if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi && - if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi && - if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi && - if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi && + if [ x"$chowncmd" != x ]; then $doit $chowncmd "$dsttmp"; else :;fi && + if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd "$dsttmp"; else :;fi && + if [ x"$stripcmd" != x ]; then $doit $stripcmd "$dsttmp"; else :;fi && + if [ x"$chmodcmd" != x ]; then $doit $chmodcmd "$dsttmp"; else :;fi && + +# Now remove or move aside any old file at destination location. We try this +# two ways since rm can't unlink itself on some systems and the destination +# file might be busy for other reasons. In this case, the final cleanup +# might fail but the new file should still install successfully. + +{ + if [ -f "$dstdir/$dstfile" ] + then + $doit $rmcmd -f "$dstdir/$dstfile" 2>/dev/null || + $doit $mvcmd -f "$dstdir/$dstfile" "$rmtmp" 2>/dev/null || + { + echo "$0: cannot unlink or rename $dstdir/$dstfile" >&2 + (exit 1); exit + } + else + : + fi +} && # Now rename the file to the real destination. - $doit $rmcmd -f $dstdir/$dstfile && - $doit $mvcmd $dsttmp $dstdir/$dstfile + $doit $mvcmd "$dsttmp" "$dstdir/$dstfile" fi && +# The final little trick to "correctly" pass the exit status to the exit trap. -exit 0 +{ + (exit 0); exit +} Index: missing =================================================================== RCS file: /home/pme/Repositories/GCC/gcc/missing,v retrieving revision 1.4 diff -u -3 -r1.4 missing --- missing 22 Jul 2000 08:08:22 -0000 1.4 +++ missing 10 Jul 2003 23:24:04 -0000 @@ -1,7 +1,7 @@ #! /bin/sh # Common stub for a few missing GNU programs while installing. -# Copyright (C) 1996, 1997 Free Software Foundation, Inc. -# Franc,ois Pinard , 1996. +# Copyright (C) 1996, 1997, 1999, 2000, 2002 Free Software Foundation, Inc. +# Originally by Fran,cois Pinard , 1996. # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -18,11 +18,37 @@ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA # 02111-1307, USA. +# As a special exception to the GNU General Public License, if you +# distribute this file as part of a program that contains a +# configuration script generated by Autoconf, you may include it under +# the same distribution terms that you use for the rest of that program. + if test $# -eq 0; then echo 1>&2 "Try \`$0 --help' for more information" exit 1 fi +run=: + +# In the cases where this matters, `missing' is being run in the +# srcdir already. +if test -f configure.ac; then + configure_ac=configure.ac +else + configure_ac=configure.in +fi + +case "$1" in +--run) + # Try to run requested program, and just exit if it succeeds. + run= + shift + "$@" && exit 0 + ;; +esac + +# If it does not exist, or fails to run (possibly an outdated version), +# try to emulate it. case "$1" in -h|--h|--he|--hel|--help) @@ -35,6 +61,7 @@ Options: -h, --help display this help and exit -v, --version output version information and exit + --run try to run the given command, and emulate it if it fails Supported PROGRAM values: aclocal touch file \`aclocal.m4' @@ -43,13 +70,15 @@ automake touch all \`Makefile.in' files bison create \`y.tab.[ch]', if possible, from existing .[ch] flex create \`lex.yy.c', if possible, from existing .c + help2man touch the output file lex create \`lex.yy.c', if possible, from existing .c makeinfo touch the output file + tar try tar, gnutar, gtar, then tar without non-portable flags yacc create \`y.tab.[ch]', if possible, from existing .[ch]" ;; -v|--v|--ve|--ver|--vers|--versi|--versio|--version) - echo "missing - GNU libit 0.0" + echo "missing 0.4 - GNU automake" ;; -*) @@ -58,31 +87,46 @@ exit 1 ;; - aclocal) + aclocal*) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if - you modified \`acinclude.m4' or \`configure.in'. You might want + you modified \`acinclude.m4' or \`${configure_ac}'. You might want to install the \`Automake' and \`Perl' packages. Grab them from any GNU archive site." touch aclocal.m4 ;; autoconf) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if - you modified \`configure.in'. You might want to install the + you modified \`${configure_ac}'. You might want to install the \`Autoconf' and \`GNU m4' packages. Grab them from any GNU archive site." touch configure ;; autoheader) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if - you modified \`acconfig.h' or \`configure.in'. You might want + you modified \`acconfig.h' or \`${configure_ac}'. You might want to install the \`Autoconf' and \`GNU m4' packages. Grab them from any GNU archive site." - files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in` + files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}` test -z "$files" && files="config.h" touch_files= for f in $files; do @@ -95,10 +139,15 @@ touch $touch_files ;; - automake) + automake*) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if - you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'. + you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'. You might want to install the \`Automake' and \`Perl' packages. Grab them from any GNU archive site." find . -type f -name Makefile.am -print | @@ -106,6 +155,34 @@ while read f; do touch "$f"; done ;; + autom4te) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + + echo 1>&2 "\ +WARNING: \`$1' is needed, and you do not seem to have it handy on your + system. You might have modified some files without having the + proper tools for further handling them. + You can get \`$1Help2man' as part of \`Autoconf' from any GNU + archive site." + + file=`echo "$*" | sed -n 's/.*--output[ =]*\([^ ]*\).*/\1/p'` + test -z "$file" && file=`echo "$*" | sed -n 's/.*-o[ ]*\([^ ]*\).*/\1/p'` + if test -f "$file"; then + touch $file + else + test -z "$file" || exec >$file + echo "#! /bin/sh" + echo "# Created by GNU Automake missing as a replacement of" + echo "# $ $@" + echo "exit 0" + chmod +x $file + exit 1 + fi + ;; + bison|yacc) echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if @@ -159,7 +236,37 @@ fi ;; + help2man) + if test -z "$run" && ($1 --version) > /dev/null 2>&1; then + # We have it, but it failed. + exit 1 + fi + + echo 1>&2 "\ +WARNING: \`$1' is missing on your system. You should only need it if + you modified a dependency of a manual page. You may need the + \`Help2man' package in order for those modifications to take + effect. You can get \`Help2man' from any GNU archive site." + + file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'` + if test -z "$file"; then + file=`echo "$*" | sed -n 's/.*--output=\([^ ]*\).*/\1/p'` + fi + if [ -f "$file" ]; then + touch $file + else + test -z "$file" || exec >$file + echo ".ab help2man is required to generate this page" + exit 1 + fi + ;; + makeinfo) + if test -z "$run" && (makeinfo --version) > /dev/null 2>&1; then + # We have makeinfo, but it failed. + exit 1 + fi + echo 1>&2 "\ WARNING: \`$1' is missing on your system. You should only need it if you modified a \`.texi' or \`.texinfo' file, or any other file @@ -173,6 +280,45 @@ file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file` fi touch $file + ;; + + tar) + shift + if test -n "$run"; then + echo 1>&2 "ERROR: \`tar' requires --run" + exit 1 + fi + + # We have already tried tar in the generic part. + # Look for gnutar/gtar before invocation to avoid ugly error + # messages. + if (gnutar --version > /dev/null 2>&1); then + gnutar "$@" && exit 0 + fi + if (gtar --version > /dev/null 2>&1); then + gtar "$@" && exit 0 + fi + firstarg="$1" + if shift; then + case "$firstarg" in + *o*) + firstarg=`echo "$firstarg" | sed s/o//` + tar "$firstarg" "$@" && exit 0 + ;; + esac + case "$firstarg" in + *h*) + firstarg=`echo "$firstarg" | sed s/h//` + tar "$firstarg" "$@" && exit 0 + ;; + esac + fi + + echo 1>&2 "\ +WARNING: I can't seem to be able to run \`tar' with the given arguments. + You may want to install GNU tar or Free paxutils, or check the + command line arguments." + exit 1 ;; *) Index: mkinstalldirs =================================================================== RCS file: /home/pme/Repositories/GCC/gcc/mkinstalldirs,v retrieving revision 1.2 diff -u -3 -r1.2 mkinstalldirs --- mkinstalldirs 3 Apr 1998 16:22:05 -0000 1.2 +++ mkinstalldirs 10 Jul 2003 23:24:04 -0000 @@ -2,35 +2,110 @@ # mkinstalldirs --- make directory hierarchy # Author: Noah Friedman # Created: 1993-05-16 -# Last modified: 1994-03-25 # Public domain errstatus=0 +dirmode="" -for file in ${1+"$@"} ; do - set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'` - shift - - pathcomp= - for d in ${1+"$@"} ; do - pathcomp="$pathcomp$d" - case "$pathcomp" in - -* ) pathcomp=./$pathcomp ;; - esac - - if test ! -d "$pathcomp"; then - echo "mkdir $pathcomp" 1>&2 - mkdir "$pathcomp" > /dev/null 2>&1 || lasterr=$? - fi - - if test ! -d "$pathcomp"; then - errstatus=$lasterr - fi +usage="\ +Usage: mkinstalldirs [-h] [--help] [-m mode] dir ..." - pathcomp="$pathcomp/" - done +# process command line arguments +while test $# -gt 0 ; do + case $1 in + -h | --help | --h*) # -h for help + echo "$usage" 1>&2 + exit 0 + ;; + -m) # -m PERM arg + shift + test $# -eq 0 && { echo "$usage" 1>&2; exit 1; } + dirmode=$1 + shift + ;; + --) # stop option processing + shift + break + ;; + -*) # unknown option + echo "$usage" 1>&2 + exit 1 + ;; + *) # first non-opt arg + break + ;; + esac +done + +for file +do + if test -d "$file"; then + shift + else + break + fi +done + +case $# in + 0) exit 0 ;; +esac + +case $dirmode in + '') + if mkdir -p -- . 2>/dev/null; then + echo "mkdir -p -- $*" + exec mkdir -p -- "$@" + fi + ;; + *) + if mkdir -m "$dirmode" -p -- . 2>/dev/null; then + echo "mkdir -m $dirmode -p -- $*" + exec mkdir -m "$dirmode" -p -- "$@" + fi + ;; +esac + +for file +do + set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'` + shift + + pathcomp= + for d + do + pathcomp="$pathcomp$d" + case $pathcomp in + -*) pathcomp=./$pathcomp ;; + esac + + if test ! -d "$pathcomp"; then + echo "mkdir $pathcomp" + + mkdir "$pathcomp" || lasterr=$? + + if test ! -d "$pathcomp"; then + errstatus=$lasterr + else + if test ! -z "$dirmode"; then + echo "chmod $dirmode $pathcomp" + lasterr="" + chmod "$dirmode" "$pathcomp" || lasterr=$? + + if test ! -z "$lasterr"; then + errstatus=$lasterr + fi + fi + fi + fi + + pathcomp="$pathcomp/" + done done exit $errstatus +# Local Variables: +# mode: shell-script +# sh-indentation: 2 +# End: # mkinstalldirs ends here From bonzini at gnu.org Fri Jul 11 08:11:17 2003 From: bonzini at gnu.org (Bonzini) Date: Fri, 11 Jul 2003 10:11:17 +0200 Subject: [autoconf-conversion] Updating top-level files for automake References: <20030711021451.GA7995@disaster.jaj.com> Message-ID: <004101c34784$0250f0e0$8add1d97@bonz> install.sh looks safe. missing is backwards compatible (automake 1.7 invokes with --run, older automakes did not). > + echo 1>&2 "\ > +WARNING: \`$1' is needed, and you do not seem to have it handy on your > + system. You might have modified some files without having the > + proper tools for further handling them. > + You can get \`$1Help2man' as part of \`Autoconf' from any GNU This is a typo BTW. mkinstalldirs was practically rewritten, a context diff would be better but it looks safe. Paolo From phil at jaj.com Wed Jul 16 23:51:18 2003 From: phil at jaj.com (Phil Edwards) Date: Wed, 16 Jul 2003 19:51:18 -0400 Subject: [autoconf-conversion] Updating top-level files for automake In-Reply-To: <004101c34784$0250f0e0$8add1d97@bonz> References: <20030711021451.GA7995@disaster.jaj.com> <004101c34784$0250f0e0$8add1d97@bonz> Message-ID: <20030716235118.GA14142@disaster.jaj.com> On Fri, Jul 11, 2003 at 10:11:17AM +0200, Bonzini wrote: > install.sh looks safe. > > missing is backwards compatible (automake 1.7 invokes with --run, older automakes did > not). > > > + echo 1>&2 "\ > > +WARNING: \`$1' is needed, and you do not seem to have it handy on your > > + system. You might have modified some files without having the > > + proper tools for further handling them. > > + You can get \`$1Help2man' as part of \`Autoconf' from any GNU > > This is a typo BTW. /What/ is a typo? And should we change it? > mkinstalldirs was practically rewritten, a context diff would be better but it looks > safe. Okay, when I send this to gcc-patches, I'll use -c instead of -u. Thanks, Phil From bonzini at gnu.org Sat Jul 19 08:57:29 2003 From: bonzini at gnu.org (Paolo Bonzini) Date: Sat, 19 Jul 2003 10:57:29 +0200 Subject: [autoconf-conversion] Updating top-level files for automake References: <20030711021451.GA7995@disaster.jaj.com> <004101c34784$0250f0e0$8add1d97@bonz> <20030716235118.GA14142@disaster.jaj.com> Message-ID: <005401c34dd3$c9a7a030$7316623e@philo> > > > + You can get \`$1Help2man' as part of \`Autoconf' from any GNU > > > > This is a typo BTW. > > /What/ is a typo? And should we change it? $1Help2man. It should be changed to $1 (but it is only help text). Paolo From phil at jaj.com Fri Jul 25 19:07:46 2003 From: phil at jaj.com (Phil Edwards) Date: Fri, 25 Jul 2003 15:07:46 -0400 Subject: New tools and multilibs fight with one another Message-ID: <20030725190746.GA25246@disaster.jaj.com> But it's a very subtle fight. Goes like this: Autoconf 2 has always taken note of env variables like CC. This is the norm for target libraries, since nearly all of their compiler-related settings are passed in the environment during the initial configure. Autoconf 2.5x now remembers which settings come from the environment, and what their values are. And when it needs to reconfigure, it re-passes those arguments on the configure command line. So, when a target library's configure "source"s the toplevel config-ml.in, and config-ml.in looks at the command-line args, all the env variables passed down from the toplevel are also visible in the argument list. Somewhere, some quoting gets lost. For libstdc++-v3, one of the env options is 'CXX= ...... -nostdinc++ ....' config-ml.in loops over each one of the words in CXX, and does the little "if they only typed one leading dash, make it two" helper bits, so it's "as if" 'CXX= ...... --nostdinc++ ....' Then, it tries to interpret each of the options in a manner best described as greedy: case $option in --*) ;; -*) option=-$option ;; esac [....] case $option in [....] --norecursion | --no*) ml_norecursion=yes ;; Using printf-style debugging, I've verified that it sees -nostdinc++, and thinks it's seen --norecursion. And with ml_norecursion set, the entire loop (later in the script) which creates the multilibs directory structure in the build tree is skipped. All of the target libraries Makefiles then have code which looks like if test -d $the_multilib_dir; then cd there && do everything else true; fi As a result, libstdc++ silently fails to build any multilibs. Only the primary library tree is built. And I suspect that any target library which uses a -no* flag passed down from the toplevel configure would see the same misbehavior if the new autoconf were applied. Looking at toplevel configure.in, I think that means only libjava at present. Two possible simple fixes, both in config-ml.in: 1) Kill that "add a leading dash" bit. 2) Stop assuming that anything beginning with --no must be --no-recursion. (We can insert the - in the middle of the word while we're at it.) Other fixes are not so simple. Clearly config-ml.in should not be looking "inside" env variables, but I don't know how to change that. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From ian at airs.com Fri Jul 25 19:13:06 2003 From: ian at airs.com (Ian Lance Taylor) Date: 25 Jul 2003 12:13:06 -0700 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: <20030725190746.GA25246@disaster.jaj.com> References: <20030725190746.GA25246@disaster.jaj.com> Message-ID: Phil Edwards writes: > So, when a target library's configure "source"s the toplevel config-ml.in, > and config-ml.in looks at the command-line args, all the env variables > passed down from the toplevel are also visible in the argument list. > > Somewhere, some quoting gets lost. My guess is that the quoting is lost here: ml_arguments="${ac_configure_args}" ... for option in ${ml_arguments} I see no real need for the ml_arguments variable. Try simply replacing all uses of ml_arguments with ac_configure_args in config-ml.in. Ian From phil at jaj.com Fri Jul 25 19:21:05 2003 From: phil at jaj.com (Phil Edwards) Date: Fri, 25 Jul 2003 15:21:05 -0400 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: References: <20030725190746.GA25246@disaster.jaj.com> Message-ID: <20030725192105.GA25770@disaster.jaj.com> On Fri, Jul 25, 2003 at 12:13:06PM -0700, Ian Lance Taylor wrote: > I see no real need for the ml_arguments variable. Try simply > replacing all uses of ml_arguments with ac_configure_args in > config-ml.in. No joy. config.status: creating config.h config.status: executing default-1 commands XXXXX config-ml.in --nostdinc++ sets ml_norecursion to yes -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From phil at jaj.com Fri Jul 25 19:33:18 2003 From: phil at jaj.com (Phil Edwards) Date: Fri, 25 Jul 2003 15:33:18 -0400 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: <20030725192105.GA25770@disaster.jaj.com> References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> Message-ID: <20030725193318.GA25942@disaster.jaj.com> On Fri, Jul 25, 2003 at 03:21:05PM -0400, Phil Edwards wrote: > On Fri, Jul 25, 2003 at 12:13:06PM -0700, Ian Lance Taylor wrote: > > I see no real need for the ml_arguments variable. Try simply > > replacing all uses of ml_arguments with ac_configure_args in > > config-ml.in. > > No joy. > > config.status: creating config.h > config.status: executing default-1 commands > XXXXX config-ml.in --nostdinc++ sets ml_norecursion to yes It looks like some single-quotes are not being interpreted properly. After making the replacement like you suggested (which I agree is a good idea), I also made this change: for option in ${ac_configure_args} do case $option in --*) ;; # -*) option=-$option ;; -*) echo "XXXXX Not touching $option" > /dev/tty ;; esac and got this: XXXXX Not touching -B/mnt/build/build-2003-07-25/gcc/ XXXXX Not touching -B/mnt/build/install-2003-07-25/i686-pc-linux-gnu/bin/ XXXXX Not touching -B/mnt/build/install-2003-07-25/i686-pc-linux-gnu/lib/ XXXXX Not touching -isystem XXXXX Not touching -isystem * XXXXX Not touching -L/mnt/build/build-2003-07-25/ld' XXXXX Not touching -g * XXXXX Not touching -O2' XXXXX Not touching -g * XXXXX Not touching -O2' XXXXX Not touching -O2 * XXXXX Not touching -D_GNU_SOURCE' XXXXX Not touching -shared-libgcc XXXXX Not touching -B/mnt/build/build-2003-07-25/gcc/ XXXXX Not touching -nostdinc++ XXXXX Not touching -L/mnt/build/build-2003-07-25/i686-pc-linux-gnu/libstdc++-v3/src XXXXX Not touching -L/mnt/build/build-2003-07-25/i686-pc-linux-gnu/libstdc++-v3/src/.libs XXXXX Not touching -B/mnt/build/install-2003-07-25/i686-pc-linux-gnu/bin/ XXXXX Not touching -B/mnt/build/install-2003-07-25/i686-pc-linux-gnu/lib/ XXXXX Not touching -isystem XXXXX Not touching -isystem * XXXXX Not touching -L/mnt/build/build-2003-07-25/ld' Note the appearance of lone single quotes. -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From ian at airs.com Fri Jul 25 20:16:28 2003 From: ian at airs.com (Ian Lance Taylor) Date: 25 Jul 2003 13:16:28 -0700 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: <20030725193318.GA25942@disaster.jaj.com> References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> <20030725193318.GA25942@disaster.jaj.com> Message-ID: Phil Edwards writes: > It looks like some single-quotes are not being interpreted properly. I think they are being interpreted properly--at least, they are being interpreted in accord with the sh language definition. autoconf is adding those single quotes to the values in $ac_configure_args, in lines like this: ac_configure_args="$ac_configure_args$ac_sep'$ac_arg'" However, when you then write code like for ac_arg in $ac_configure_args the shell does parameter expansion on $ac_configure_args, and then does field splitting on the result. It does't pass the result of the parameter expansion back through the quote recognition which is done on the input, nor does any quote removal step apply. That is why config-ml.in is getting messed up. In fact, I think there are similar problems in autoconf 2.57 itself, in AC_OUTPUT_SUBDIRS, and I suspect that it would be possible to mess up autoconf with carefully chosen environment variables. There is one way to get the right thing to happen, which is the way that autoconf mainly uses ac_configure_args: write it into a script, and execute the script. This effectivel forces the shell to run quote recognition on the parameter expansion. For example, with ac_configure_args set as above, something like this should print the arguments one on each line: cat >foo1.sh < References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> <20030725193318.GA25942@disaster.jaj.com> Message-ID: Ian Lance Taylor writes: > I can't think of anything else that would work. Of course, the other approach that would work would be to change autoconf to build ac_configure_args in a different way. For example, it could do something like ac_configure_args="${ac_configure_args} ACARGSPLITTER ${arg}" (note no quoting) and then do arg= for a in ${ac_configure_args}; do if test ${a} != ACARGSPLITTER; then arg="${arg} ${a}" else # process ${arg} arg= fi done Ian From phil at jaj.com Fri Jul 25 20:25:40 2003 From: phil at jaj.com (Phil Edwards) Date: Fri, 25 Jul 2003 16:25:40 -0400 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> <20030725193318.GA25942@disaster.jaj.com> Message-ID: <20030725202540.GA26578@disaster.jaj.com> On Fri, Jul 25, 2003 at 01:16:28PM -0700, Ian Lance Taylor wrote: > Phil Edwards writes: > > > It looks like some single-quotes are not being interpreted properly. > > I think they are being interpreted properly--at least, they are being > interpreted in accord with the sh language definition. Yes, of course. I didn't mean to imply the shell was broken. > This rather awful trick could be used for the argument processing in > config-ml.in. > > I can't think of anything else that would work. Basically you need to > expand the parameter and then treat it as normal shell input for quote > processing. As far as I know, the shell language doesn't support that > directly. Sigh. This is more than what I've bargained for. In the short term, I still think either of the fixes I proposed should be applied. Actually, both of them. We don't need to be sloppy about accepting arguments in our own trees. Even then, something still isn't being done correctly, but that's probably unique to libstdc++-v3, and not config-ml.in's problem. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From bonzini at gnu.org Fri Jul 25 23:32:41 2003 From: bonzini at gnu.org (Paolo Bonzini) Date: Sat, 26 Jul 2003 01:32:41 +0200 Subject: [autoconf-conversion] New tools and multilibs fight with one another References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> <20030725193318.GA25942@disaster.jaj.com> <20030725202540.GA26578@disaster.jaj.com> Message-ID: <002501c35305$0bdd24d0$6c14623e@philo> > > I can't think of anything else that would work. Basically you need to > > expand the parameter and then treat it as normal shell input for quote > > processing. As far as I know, the shell language doesn't support that > > directly. eval? Paolo From ian at airs.com Sat Jul 26 04:28:11 2003 From: ian at airs.com (Ian Lance Taylor) Date: 25 Jul 2003 21:28:11 -0700 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: <002501c35305$0bdd24d0$6c14623e@philo> References: <20030725190746.GA25246@disaster.jaj.com> <20030725192105.GA25770@disaster.jaj.com> <20030725193318.GA25942@disaster.jaj.com> <20030725202540.GA26578@disaster.jaj.com> <002501c35305$0bdd24d0$6c14623e@philo> Message-ID: "Paolo Bonzini" writes: > > > I can't think of anything else that would work. Basically you need to > > > expand the parameter and then treat it as normal shell input for quote > > > processing. As far as I know, the shell language doesn't support that > > > directly. > > eval? You're right, that does work. For some reason I was thinking that eval would create a subshell, but that was wrong. So you can do something like this: eval "for a in ${ac_configure_args}; do PROCESS ARG; done" That is simpler. Ian From bonzini at gnu.org Sat Jul 26 11:41:30 2003 From: bonzini at gnu.org (Paolo Bonzini) Date: Sat, 26 Jul 2003 13:41:30 +0200 Subject: [autoconf-conversion] New tools and multilibs fight with one another References: <20030725190746.GA25246@disaster.jaj.com><20030725192105.GA25770@disaster.jaj.com><20030725193318.GA25942@disaster.jaj.com><20030725202540.GA26578@disaster.jaj.com><002501c35305$0bdd24d0$6c14623e@philo> Message-ID: <001f01c3536a$dc1fdba0$f810623e@philo> > eval "for a in ${ac_configure_args}; do PROCESS ARG; done" You can't that is a standard use of eval though :-) Paolo From phil at jaj.com Sat Jul 26 20:44:12 2003 From: phil at jaj.com (Phil Edwards) Date: Sat, 26 Jul 2003 16:44:12 -0400 Subject: [autoconf-conversion] New tools and multilibs fight with one another In-Reply-To: <001f01c3536a$dc1fdba0$f810623e@philo> References: <001f01c3536a$dc1fdba0$f810623e@philo> Message-ID: <20030726204412.GA9110@disaster.jaj.com> On Sat, Jul 26, 2003 at 01:41:30PM +0200, Paolo Bonzini wrote: > > eval "for a in ${ac_configure_args}; do PROCESS ARG; done" > > You can't that is a standard use of eval though :-) Yeah, I've seen eval used in some weird places, but I'm not going to try and add the quoting necessary to make it work here. (I must admit I thought eval did its work in a subshell, too.) -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From phil at jaj.com Sun Jul 27 23:33:13 2003 From: phil at jaj.com (Phil Edwards) Date: Sun, 27 Jul 2003 19:33:13 -0400 Subject: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030726205855.GA9281@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> Message-ID: <20030727233313.GA23583@disaster.jaj.com> On Sat, Jul 26, 2003 at 04:58:55PM -0400, Phil Edwards wrote: > > > libstdcxx_flags='`test ! -f > > >$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags || $(SHELL) > > >$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags > > >--build-includes` -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src > > >-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs' > > > raw_libstdcxx_flags=' -L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src > > >-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs' > > > > > >Note the -L options; these get embedded into CXX_FOR_TARGET a few lines > > >later, which becomes CXX inside the library. [...] > Also, I'm having trouble understanding how this manages to work at present, > i.e., with the "old" autotools. The -L options are still hardcoded > either way. Okay, I've figured this part out, and why it's breaking. I'm going to need some help to make this work. To make things clearer in this email, I'm going to pretend that the CXX variable for a normal primary build is set to Primary. (It's actully a long "..../xgcc -B... -L..." string.) So, when the primary v3 configure is run, the toplevel does it via CXX=Primary $srcdir/configure --stuff Clear? Now, at the end of that run, config.status is generated and executed. It source's config-ml.in, which runs through the list of multilib subdirs, and does text substitution on the env variables. Pretend we have one multilib, and I'll call the CXX variable for that one Multilib: # config-ml.in does this Multilib=`echo Primary | sed 's/references-to-primary-dir/references-to-multilib-dir'` cd up-and-over-to-multilib-dir/libstdc++-v3 CXX=Multilib $srcdir/configure --stuff Where "--stuff" is everything that was passed to configure. This list of args is stored in config.status. Remember that for later. That's why hardcoding things like -L into CXX at the top level still work for multilibs. Still clear? Since the days of autoconf 2.13, it has been obverved that people try to do things like this, in general: $ CC=foo ./configure $ make [something breaks, requiring a reconfigure] $ ./configure [oops, CC wasn't set this time, different compilers are found during the tests, hilarity ensues] To protect the users from themselves, autoconf 2.5x takes note of "precious" variables in the environment, and remembers them. $ CC=foo ./configure $ make [something breaks, requiring a reconfigure] $ ./configure configure: error: you're being a dumbass! To be both safe and helpful, the configure script actually stores those variables into the generated config.status file -- pay attention now -- as if they had been specified on the command line. The shell variable which stores command-line arguments is augmented with those "precious" environment variables. So when a multilib run is fired off with configure generated by 2.57, the created primary config.status source's config-ml.in, which then does this just as before: Multilib=`echo Primary | sed '.....'` CXX=Multilib $srcdir/configure --stuff 'CXX=Primary' When configure examines the command line and sees variable assignments, it performs them without examining the current environment. It does this for safety, because it thinks the user is rerunning configure. That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it overwrites Multilib with Primary. I've made a couple of half-hearted attempts to defeat this from within libstdc++'s acinclude.m4, but autoconf is too smart for me. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From zack at codesourcery.com Sun Jul 27 23:49:26 2003 From: zack at codesourcery.com (Zack Weinberg) Date: Sun, 27 Jul 2003 16:49:26 -0700 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030727233313.GA23583@disaster.jaj.com> (Phil Edwards's message of "Sun, 27 Jul 2003 19:33:13 -0400") References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> Message-ID: <87smor7cop.fsf@egil.codesourcery.com> Phil Edwards writes: > So, when the primary v3 configure is run, > the toplevel does it via > > CXX=Primary $srcdir/configure --stuff > > Clear? > > Now, at the end of that run, config.status is generated and executed. > It source's config-ml.in, which runs through the list of multilib subdirs, > and does text substitution on the env variables. Pretend we have one > multilib, and I'll call the CXX variable for that one Multilib: > > # config-ml.in does this > Multilib=`echo Primary | sed 's/references-to-primary-dir/references-to-multilib-dir'` > > cd up-and-over-to-multilib-dir/libstdc++-v3 > CXX=Multilib $srcdir/configure --stuff It seems to me that the problem is right here: we shouldn't have this Primary/Multilib distinction in the first place. Suppose we hoist all the iteration over multilibs up to the top level Makefile. Then each multilib directory gets configured as a 'primary' and the symptoms you've observed vanish. I want this for other reasons - specifically, I want to be able to set up a multilib set that doesn't have any primary (default). zw From drow at mvista.com Sun Jul 27 23:50:40 2003 From: drow at mvista.com (Daniel Jacobowitz) Date: Sun, 27 Jul 2003 19:50:40 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030727233313.GA23583@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> Message-ID: <20030727235039.GA19415@nevyn.them.org> On Sun, Jul 27, 2003 at 07:33:13PM -0400, Phil Edwards wrote: > To be both safe and helpful, the configure script actually stores those > variables into the generated config.status file -- pay attention now -- > as if they had been specified on the command line. The shell variable > which stores command-line arguments is augmented with those "precious" > environment variables. > > > So when a multilib run is fired off with configure generated by 2.57, > the created primary config.status source's config-ml.in, which then does > this just as before: > > Multilib=`echo Primary | sed '.....'` > > CXX=Multilib $srcdir/configure --stuff 'CXX=Primary' > > When configure examines the command line and sees variable assignments, > it performs them without examining the current environment. It does this > for safety, because it thinks the user is rerunning configure. > > That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it > overwrites Multilib with Primary. > > > I've made a couple of half-hearted attempts to defeat this from within > libstdc++'s acinclude.m4, but autoconf is too smart for me. Can't you just modify what config.status thinks the command line was, at this point? Either to correct Primary, or to append CXX=Multilib? Presumably from within config-ml.in. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From phil at jaj.com Sun Jul 27 23:58:57 2003 From: phil at jaj.com (Phil Edwards) Date: Sun, 27 Jul 2003 19:58:57 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <87smor7cop.fsf@egil.codesourcery.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <87smor7cop.fsf@egil.codesourcery.com> Message-ID: <20030727235857.GA24231@disaster.jaj.com> On Sun, Jul 27, 2003 at 04:49:26PM -0700, Zack Weinberg wrote: > Phil Edwards writes: > > > So, when the primary v3 configure is run, > > the toplevel does it via > > > > CXX=Primary $srcdir/configure --stuff > > > > Clear? > > > > Now, at the end of that run, config.status is generated and executed. > > It source's config-ml.in, which runs through the list of multilib subdirs, > > and does text substitution on the env variables. Pretend we have one > > multilib, and I'll call the CXX variable for that one Multilib: > > > > # config-ml.in does this > > Multilib=`echo Primary | sed 's/references-to-primary-dir/references-to-multilib-dir'` > > > > cd up-and-over-to-multilib-dir/libstdc++-v3 > > CXX=Multilib $srcdir/configure --stuff > > It seems to me that the problem is right here: we shouldn't have this > Primary/Multilib distinction in the first place. Suppose we hoist all > the iteration over multilibs up to the top level Makefile. Then each > multilib directory gets configured as a 'primary' and the symptoms > you've observed vanish. > > I want this for other reasons - specifically, I want to be able to set > up a multilib set that doesn't have any primary (default). Nathanael also wants this, and I think it would probably be a good idea. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From phil at jaj.com Mon Jul 28 00:01:05 2003 From: phil at jaj.com (Phil Edwards) Date: Sun, 27 Jul 2003 20:01:05 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030727235039.GA19415@nevyn.them.org> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030727235039.GA19415@nevyn.them.org> Message-ID: <20030728000105.GB24231@disaster.jaj.com> On Sun, Jul 27, 2003 at 07:50:40PM -0400, Daniel Jacobowitz wrote: > On Sun, Jul 27, 2003 at 07:33:13PM -0400, Phil Edwards wrote: > > To be both safe and helpful, the configure script actually stores those > > variables into the generated config.status file -- pay attention now -- > > as if they had been specified on the command line. The shell variable > > which stores command-line arguments is augmented with those "precious" > > environment variables. > > > > > > So when a multilib run is fired off with configure generated by 2.57, > > the created primary config.status source's config-ml.in, which then does > > this just as before: > > > > Multilib=`echo Primary | sed '.....'` > > > > CXX=Multilib $srcdir/configure --stuff 'CXX=Primary' > > > > When configure examines the command line and sees variable assignments, > > it performs them without examining the current environment. It does this > > for safety, because it thinks the user is rerunning configure. > > > > That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it > > overwrites Multilib with Primary. > > > > > > I've made a couple of half-hearted attempts to defeat this from within > > libstdc++'s acinclude.m4, but autoconf is too smart for me. > > Can't you just modify what config.status thinks the command line was, > at this point? Either to correct Primary, or to append CXX=Multilib? > Presumably from within config-ml.in. Correcting Primary is tricky without the toplevel knowing more about multilibs. Appending CXX=Multilib would have to be done within config-ml.in, and I believe would work, but would also break all 2.13-style configures, which (IIRC) didn't understand env assignments as command-line arguments. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From drow at mvista.com Mon Jul 28 00:16:24 2003 From: drow at mvista.com (Daniel Jacobowitz) Date: Sun, 27 Jul 2003 20:16:24 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030728000105.GB24231@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030727235039.GA19415@nevyn.them.org> <20030728000105.GB24231@disaster.jaj.com> Message-ID: <20030728001624.GA1090@nevyn.them.org> On Sun, Jul 27, 2003 at 08:01:05PM -0400, Phil Edwards wrote: > On Sun, Jul 27, 2003 at 07:50:40PM -0400, Daniel Jacobowitz wrote: > > On Sun, Jul 27, 2003 at 07:33:13PM -0400, Phil Edwards wrote: > > > To be both safe and helpful, the configure script actually stores those > > > variables into the generated config.status file -- pay attention now -- > > > as if they had been specified on the command line. The shell variable > > > which stores command-line arguments is augmented with those "precious" > > > environment variables. > > > > > > > > > So when a multilib run is fired off with configure generated by 2.57, > > > the created primary config.status source's config-ml.in, which then does > > > this just as before: > > > > > > Multilib=`echo Primary | sed '.....'` > > > > > > CXX=Multilib $srcdir/configure --stuff 'CXX=Primary' > > > > > > When configure examines the command line and sees variable assignments, > > > it performs them without examining the current environment. It does this > > > for safety, because it thinks the user is rerunning configure. > > > > > > That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it > > > overwrites Multilib with Primary. > > > > > > > > > I've made a couple of half-hearted attempts to defeat this from within > > > libstdc++'s acinclude.m4, but autoconf is too smart for me. > > > > Can't you just modify what config.status thinks the command line was, > > at this point? Either to correct Primary, or to append CXX=Multilib? > > Presumably from within config-ml.in. > > Correcting Primary is tricky without the toplevel knowing more about > multilibs. Appending CXX=Multilib would have to be done within config-ml.in, > and I believe would work, but would also break all 2.13-style configures, > which (IIRC) didn't understand env assignments as command-line arguments. Is this code run once per subdirectory per multilib, or once per multilib? If the former we could just check which configure we're passing off to. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From phil at jaj.com Mon Jul 28 00:38:27 2003 From: phil at jaj.com (Phil Edwards) Date: Sun, 27 Jul 2003 20:38:27 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030728001624.GA1090@nevyn.them.org> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030727235039.GA19415@nevyn.them.org> <20030728000105.GB24231@disaster.jaj.com> <20030728001624.GA1090@nevyn.them.org> Message-ID: <20030728003827.GA24917@disaster.jaj.com> On Sun, Jul 27, 2003 at 08:16:24PM -0400, Daniel Jacobowitz wrote: > > Correcting Primary is tricky without the toplevel knowing more about > > multilibs. Appending CXX=Multilib would have to be done within config-ml.in, > > and I believe would work, but would also break all 2.13-style configures, > > which (IIRC) didn't understand env assignments as command-line arguments. > > Is this code run once per subdirectory per multilib, or once per > multilib? If the former we could just check which configure we're > passing off to. Once per multilib; it's build along with every variant of the library. -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From phil at jaj.com Mon Jul 28 19:54:14 2003 From: phil at jaj.com (Phil Edwards) Date: Mon, 28 Jul 2003 15:54:14 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030727233313.GA23583@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> Message-ID: <20030728195414.GA6633@disaster.jaj.com> On Sun, Jul 27, 2003 at 07:33:13PM -0400, Phil Edwards wrote: > > When configure examines the command line and sees variable assignments, > it performs them without examining the current environment. It does this > for safety, because it thinks the user is rerunning configure. > > That sound you hear is configure wailing, "MY PRECIOUSSSSSSSS!" as it > overwrites Multilib with Primary. > > I've made a couple of half-hearted attempts to defeat this from within > libstdc++'s acinclude.m4, but autoconf is too smart for me. I wasn't being evil enough. *cackle* I have sneakily removed the bit of shell code in configure which treats CXX as a "precious" variable. Other precious variables are still passed around but CXX is correctly inherited from the environment like we want it to be. (Since libstdc++ is no longer shipped on its own, I'm not worried about end-users making the reconfigure mistake. The library is /always/ configured via the toplevel.) This works, and unless somebody has better suggestions, I'm probably going to use it for a short-term fix. How short? Long enough to complete the transition to the new tools and check things in, where other people can begin hacking on them. Moving multilib knowledge to the toplevel is sounding better and better as the proper solution, at which point the evil can be removed. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From bonzini at gnu.org Mon Jul 28 22:02:29 2003 From: bonzini at gnu.org (Paolo Bonzini) Date: Tue, 29 Jul 2003 00:02:29 +0200 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030728195414.GA6633@disaster.jaj.com> Message-ID: <001a01c35553$f2228160$1f13623e@philo> > *cackle* I have sneakily removed the bit of shell code in configure which > treats CXX as a "precious" variable. Other precious variables are still > passed around but CXX is correctly inherited from the environment like we > want it to be. Why not CC, AS and LD too? I wonder if autoupdating newlib and other parts of the unified tree will have similar issues. Also, did you do this by modifying the configure script manually or by overriding an Autoconf macro definition? Paolo From phil at jaj.com Mon Jul 28 22:41:24 2003 From: phil at jaj.com (Phil Edwards) Date: Mon, 28 Jul 2003 18:41:24 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <001a01c35553$f2228160$1f13623e@philo> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030728195414.GA6633@disaster.jaj.com> <001a01c35553$f2228160$1f13623e@philo> Message-ID: <20030728224124.GA8976@disaster.jaj.com> On Tue, Jul 29, 2003 at 12:02:29AM +0200, Paolo Bonzini wrote: > > *cackle* I have sneakily removed the bit of shell code in configure which > > treats CXX as a "precious" variable. Other precious variables are still > > passed around but CXX is correctly inherited from the environment like we > > want it to be. > > Why not CC, AS and LD too? I wonder if autoupdating newlib and other parts > of the unified tree will have similar issues. Because AS and LD aren't touched by config-ml.in, and libstdc++-v3 doesn't use $CC (or should be, at least.) My local-changes tree happens to be a unified one, and I didn't have any problem with the faked multilib build (for whatever that's worth). > Also, did you do this by modifying the configure script manually or by > overriding an Autoconf macro definition? The latter. -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From bonzini at gnu.org Mon Jul 28 22:29:42 2003 From: bonzini at gnu.org (Paolo Bonzini) Date: Tue, 29 Jul 2003 00:29:42 +0200 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030728195414.GA6633@disaster.jaj.com> <001a01c35553$f2228160$1f13623e@philo> <20030728224124.GA8976@disaster.jaj.com> Message-ID: <005601c35557$bf711200$1f13623e@philo> > Because AS and LD aren't touched by config-ml.in, and libstdc++-v3 doesn't > use $CC (or should be, at least.) Ok, a silly question... > My local-changes tree happens to be a unified one, and I didn't have any > problem with the faked multilib build (for whatever that's worth). That's good, but I think CC should be preserved too. You might multilib on -mrtd or -mregparm=3 if you're building for x86, which will definitely break things if they go wrong. That's much less faked and, to some extent, it might even be useful (but not in an unified tree, as it will interact with assembly language files in newlib and BTW also in libffi -- so no Java as well). > > Also, did you do this by modifying the configure script manually or by > > overriding an Autoconf macro definition? > > The latter. Which is great. Paolo From phil at jaj.com Mon Jul 28 22:58:20 2003 From: phil at jaj.com (Phil Edwards) Date: Mon, 28 Jul 2003 18:58:20 -0400 Subject: [autoconf-conversion] Re: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <005601c35557$bf711200$1f13623e@philo> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030728195414.GA6633@disaster.jaj.com> <001a01c35553$f2228160$1f13623e@philo> <20030728224124.GA8976@disaster.jaj.com> <005601c35557$bf711200$1f13623e@philo> Message-ID: <20030728225820.GA9157@disaster.jaj.com> On Tue, Jul 29, 2003 at 12:29:42AM +0200, Paolo Bonzini wrote: > > My local-changes tree happens to be a unified one, and I didn't have any > > problem with the faked multilib build (for whatever that's worth). > > That's good, but I think CC should be preserved too. Actually, I think I /want/ $CC to break in libstdc++-v3. It'll be a warning flag, since it shouldn't be used. (Right now, we use it twice, but only the driver, not the actual compiler, and I'll be changing it to use $CXX instead.) > You might multilib on -mrtd or -mregparm=3 if you're building for x86, which > will definitely break things if they go wrong. That's much less faked and, > to some extent, it might even be useful (but not in an unified tree, as it > will interact with assembly language files in newlib and BTW also in > libffi -- so no Java as well). Actually, we've got a couple of sparc tests going now, which are multilibbed for real. > > > Also, did you do this by modifying the configure script manually or by > > > overriding an Autoconf macro definition? > > > > The latter. > > Which is great. Absolutely. I'm crazy, but I'm not insane. :-) -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From aoliva at redhat.com Thu Jul 31 04:04:10 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 31 Jul 2003 01:04:10 -0300 Subject: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030727233313.GA23583@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> Message-ID: On Jul 27, 2003, Phil Edwards wrote: > It source's config-ml.in, which runs through the list of multilib subdirs, > and does text substitution on the env variables. And then it modifies CXX, and passes that to each multilib's configure. Since each multilib uses separate config.cache and separate config.status, I don't see why the wrong CXX would be cached in them. Isn't config-ml.in doing its job properly? Or is the primary multilib inappropriately passing CXX to other multilibs' makefiles? -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer From phil at jaj.com Thu Jul 31 18:15:41 2003 From: phil at jaj.com (Phil Edwards) Date: Thu, 31 Jul 2003 14:15:41 -0400 Subject: Toplevel configury, multilibs, new autoconf versions In-Reply-To: References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> Message-ID: <20030731181541.GA4587@disaster.jaj.com> On Thu, Jul 31, 2003 at 01:04:10AM -0300, Alexandre Oliva wrote: > On Jul 27, 2003, Phil Edwards wrote: > > > It source's config-ml.in, which runs through the list of multilib subdirs, > > and does text substitution on the env variables. > > And then it modifies CXX, and passes that to each multilib's > configure. Since each multilib uses separate config.cache and > separate config.status, I don't see why the wrong CXX would be cached > in them. Isn't config-ml.in doing its job properly? Or is the > primary multilib inappropriately passing CXX to other multilibs' > makefiles? Nothing to do with the cache. It's the passing of environment variables on the command line (later in my message). -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams From aoliva at redhat.com Thu Jul 31 19:38:41 2003 From: aoliva at redhat.com (Alexandre Oliva) Date: 31 Jul 2003 16:38:41 -0300 Subject: Toplevel configury, multilibs, new autoconf versions In-Reply-To: <20030731181541.GA4587@disaster.jaj.com> References: <20030726051610.GA1871@twcny.rr.com> <20030726205855.GA9281@disaster.jaj.com> <20030727233313.GA23583@disaster.jaj.com> <20030731181541.GA4587@disaster.jaj.com> Message-ID: On Jul 31, 2003, Phil Edwards wrote: > Nothing to do with the cache. It's the passing of environment variables > on the command line (later in my message). Ah... So autoconf adds CC and CXX settings to ac_configure_args? Eeek. Yeah, I see that this could be a problem :-( One more reason to move multilibbing to the top level. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer