Possibly related to (or a duplicate of) bug 11273. Configured with CONFIG_SHELL=/bin/bash, bootstrapped, then during installation: gmake[5]: Entering directory `/tmp/pedwards/objdir/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/libsupc++' /bin/bash ../../../../../gcc-3.3/libstdc++-v3/../mkinstalldirs /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9 /bin/bash ../libtool --mode=install /bin/bash /tmp/pedwards/gcc-3.3/install-sh -c libsupc++.la /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9/libsupc++.la libtool: install: `/usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9/libsupc++.la' is not a directory Try `libtool --help --mode=install' for more information. gmake[5]: *** [install-toolexeclibLTLIBRARIES] Error 1 Entering that directory and running the install command manually fails: % /bin/bash ../libtool --mode=install /bin/bash /tmp/pedwards/gcc-3.3/install-sh -c libsupc++.la /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9 /bin/bash /tmp/pedwards/gcc-3.3/install-sh /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9/install-sh install: /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9/install-sh does not exist Running the command manually, but deleting the second "/bin/bash" works: % /bin/bash ../libtool --mode=install /tmp/pedwards/gcc-3.3/install-sh -c libsupc++.la /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/sparcv9 [...] The result is the same as bug 11273; editing the Makefile and changing the INSTALL* variables to call install-sh directly rather than as an argument to a shell; apparently install-sh isn't set up to handle that.
I spoke too soon. Since the values in the target Makefiles are constantly being overridden by higher Makefiles, editing the target Makefiles to change INSTALL* has no effect. I tried gmake INSTALL="/srcdir/install-sh -c" INSTALL_DATA="..." INSTALL_PROGRAM="..." INSTALL_SCRIPT="..." install which helped, but only to a limited extent: gmake[4]: Entering directory `/tmp/pedwards/objdir/sparc-sun-solaris2.8/sparcv9/libf2c' gmake[4]: `libg2c.la' is up to date. gmake[4]: Leaving directory `/tmp/pedwards/objdir/sparc-sun-solaris2.8/sparcv9/libf2c' : gmake ; exec true CC='/tmp/pedwards/objdir/gcc/xgcc -B/tmp/pedwards/objdir/gcc/ -B/usr/local/SW/GCC/3.3-ld/sparc-sun-solaris2.8/bin/ -B/usr/local/SW/GCC/3.3-ld/sparc-sun-solaris2.8/lib/ -isystem /usr/local/SW/GCC/3.3-ld/sparc-sun-solaris2.8/include' LD='/usr/local/SW/binutils-2.14/bin/ld' LIBTOOL='/bin/bash ./libtool' WARN_CFLAGS='-W -Wall' CFLAGS='-O2 -g -m64' CPPFLAGS='' DESTDIR='' AR='ar' RANLIB='true' prefix='/usr/local/SW/GCC/3.3-ld' exec_prefix='/usr/local/SW/GCC/3.3-ld' libdir='/usr/local/SW/GCC/3.3-ld/lib' libsubdir='/usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3' tooldir='/usr/local/SW/GCC/3.3-ld/sparc-sun-solaris2.8' multi-do DO="all-unilib" /bin/sh ../../../../gcc-3.3/libf2c/../mkinstalldirs /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8//sparcv9 mkdir /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/sparcv9 /bin/bash ./libtool --mode=install /bin/bash /tmp/pedwards/gcc-3.3/install-sh -c libg2c.la /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8//sparcv9 /bin/bash /tmp/pedwards/gcc-3.3/install-sh /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8//sparcv9/install-sh install: /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8//sparcv9/install-sh does not exist gmake[3]: *** [install] Error 1 gmake[3]: Leaving directory `/tmp/pedwards/objdir/sparc-sun-solaris2.8/sparcv9/libf2c' I'm beginning to understand why GCC 2.95 and 3.0 are the only versions ever installed on these systems. Between that mess and this kind of thing: if [ -f fixhdr.ready ] ; then \ true; \ else \ echo timestamp > fixhdr.ready; \ fi rm -rf /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/include mkdir /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/include chmod a+rx /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/include (cd `/tmp/pedwards/objdir/gcc`/include ; \ tar -cf - .; exit 0) | (cd /usr/local/SW/GCC/3.3-ld/lib/gcc-lib/sparc-sun-solaris2.8/3.3/include; tar xpf - ) /bin/bash: /tmp/pedwards/objdir/gcc: is a directory /bin/bash: cd: /include: No such file or directory
Happens again using 3.3 from 2003-07-10, with CONFIG_SHELL=/bin/ksh and /usr/bin at the front of the PATH (i.e., no POSIX utils from /usr/xpg4). Libtool doesn't know, and probably shouldn't be expected to figure out, that INSTALL_* consists of multiple words, in this case, "/bin/ksh ...../install-sh". gmake[5]: Entering directory `/tmp/pedwards/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/libsupc++' /bin/ksh ../../../../../3.3/libstdc++-v3/../mkinstalldirs /usr/local/SW/GCC/3.3-branch-native/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/sparcv9 /bin/ksh ../libtool --mode=install /bin/ksh /tmp/pedwards/3.3/install-sh -c libsupc++.la /usr/local/SW/GCC/3.3-branch-native/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/sparcv9/libsupc++.la libtool: install: `/usr/local/SW/GCC/3.3-branch-native/lib/gcc-lib/sparc-sun-solaris2.8/3.3.1/sparcv9/libsupc++.la' is not a directory Try `libtool --help --mode=install' for more information. gmake[5]: *** [install-toolexeclibLTLIBRARIES] Error 1
Well, cuss words. Configuring as before (CONFIG_SHELL=/bin/ksh) but with --disable-multilib still gives the same error, just in a different directory.
Created attachment 4384 [details] Patch to let autoconf determine install Well, the top level determines INSTALL & friends in a really old-fashioned pre-autoconfy way. Let's see if autoconfiscating this helps. This is untested. You'll have to regenerate configure. You'll also have to regenerate Makefile.in, but if you haven't got autogen, just apply the Makefile.tpl patch to Makefile.in as well (it gives the same results in this case).
Oh, wait, um... this is only gonna work for 3.4, since 3.3 wasn't autoconfiscated. Anyway, if you can reproduce the bug on mainline, could you give my patch a try so we can fix it on mainline? Then I'll take a look at 3.3.
I will try a mainline build as soon as I can get the sources over there.
Subject: Bug 11408 CVSROOT: /cvs/gcc Module name: gcc Changes by: neroden@gcc.gnu.org 2003-07-13 20:47:32 Modified files: . : ChangeLog Makefile.tpl Makefile.in configure.in configure Log message: PR bootstrap/11273 PR bootstrap/11408 * Makefile.tpl: Set INSTALL and friends using autoconf. Remove unused INSTALL_PROGRAM_ARGS. * configure.in: Use AC_PROG_INSTALL. * Makefile.in: Regenerate. * configure: Regenerate. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.770&r2=1.771 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.tpl.diff?cvsroot=gcc&r1=1.65&r2=1.66 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.181&r2=1.182 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcc&r1=1.245&r2=1.246 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&r1=1.104&r2=1.105
Could the reporter please retest using mainline CVS? I believe the bug should be fixed there now.
Mainline CVS fails to bootstrap. Once I can get to the installation stage, I'll let you know...
This is blocking bootstraps on Solaris.
Resummarizing based on this effects everyone who uses CONFIG_SHELL, it just blocks solaris because the sh in there is not enough to bootstrap. It does not look like there is any easy way to fix this without changing the toplevel configure/ makefile to autoconf based one.
Created attachment 4408 [details] Patch for 3.3 to strip $(SHELL) off of $(INSTALL) This is the simplistic "solution" for 3.3. See if it works. I was going to wait and see if the solution applied to mainline worked there before putting this out, but since Solaris isn't bootstrapping on mainline :-( and this is holding up 3.3, I guess I'll just throw this out right now.
I don't think the problem is the double /bin/ksh per se because it works for me on Solaris 2.5.1, 2.6, 7, 8 and 9.
Postponed until GCC 3.3.2. Eric and Phil collaborated on installation documentation that explains what to do to build on Solaris. We can reconsider doing something more than documentation for 3.3.2.
Not mine; I've done what I can.
*** Bug 11615 has been marked as a duplicate of this bug. ***
Mainline fails to install (2003-07-21) because INSTALL uses a relative path to refer to toplevel instahll-sh. As soon as the install process goes down to the gcc subdir, "../sourcedir/install-sh" no longer exists. The toplevel $srcdir variable itself is no longer being canonicalized to an absolute path. I think it used to be. In any case, INSTALL definitely needs to be an absolute path. In the meantime, I'll configure with an absolute path to 'configure'.
I've been told that we *must not* absolutize ${srcdir}, for some reason or other (NFS mounts?).
Not NFS mounts, but automounters tend to get confused. Thus this fragment, snipped from libstdc++'s configury: # 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. glibcxx_builddir=`${PWDCMD-pwd}` case $srcdir in [\\/$]* | ?:[\\/]*) glibcxx_srcdir=${srcdir} ;; *) glibcxx_srcdir=`cd "$srcdir" && ${PWDCMD-pwd} || echo "$srcdir"` ;; esac So I guess srcdir needs to stay unchanged. However, INSTALL does need to be fixed, somehow; that's the actual bug. (The srcdir thing just caught my attention.)
Subject: Re: installation fails for many target libraries using CONFIG_SHELL It seems like this problem is really more w/ libtool than w/ the makefile because if I remove the leading /bin/ksh from the INSTALL value it seems to fix the problem. I haven't had a chance to delve into the code of libtool, but perhaps it just doesn't know how to interpret the two part command. Richard pme at gcc dot gnu dot org wrote: >PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11408 > > > >------- Additional Comments From pme at gcc dot gnu dot org 2003-07-21 23:06 ------- >Not NFS mounts, but automounters tend to get confused. Thus this fragment, >snipped from libstdc++'s configury: > > # 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. > glibcxx_builddir=`${PWDCMD-pwd}` > case $srcdir in > [\\/$]* | ?:[\\/]*) glibcxx_srcdir=${srcdir} ;; > *) glibcxx_srcdir=`cd "$srcdir" && ${PWDCMD-pwd} || echo "$srcdir"` ;; > esac > >So I guess srcdir needs to stay unchanged. However, INSTALL does need to be >fixed, somehow; that's the actual bug. (The srcdir thing just caught my >attention.) > > > > > >------- You are receiving this mail because: ------- >You are on the CC list for the bug, or are watching someone who is. > > >
The gcc subdirectory doesn't use libtool to install binaries like "g++". And that's one of the files that can't be installed because a relative $INSTALL points to a real file only at the top of the build tree.
Subject: Re: installation fails for many target libraries using CONFIG_SHELL When looking at the Makefile though the $INSTALL value is not relative. It is fully qualified, unless I'm looking in the wrong spot. There seem to only be a few places where libtool is actually called out such as libstdc++-v3/libffi or libjava. Here is an example of the value of $INSTALL as set in the Makefile for sparc-sun-solaris2.7/sparcv9/libjava: INSTALL = /bin/ksh /export/apps/software_orig/gcc/gcc-3.3/install-sh -c Notice the /bin/ksh in front of the call to install-sh. This seems to work just fine when $INSTALL is referenced directly, but when it is called by libtool it crashes with a libtool error. pme at gcc dot gnu dot org wrote: >PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11408 > > > >------- Additional Comments From pme at gcc dot gnu dot org 2003-07-22 00:58 ------- >The gcc subdirectory doesn't use libtool to install binaries like "g++". And >that's one of the files that can't be installed because a relative $INSTALL >points to a real file only at the top of the build tree. > > > > >------- You are receiving this mail because: ------- >You are on the CC list for the bug, or are watching someone who is. > > >
Subject: Re: installation fails for many target libraries using CONFIG_SHELL If I modify the top level Makefile immediately after running configure and make the following change #INSTALL = $(SHELL) $$s/install-sh -c INSTALL = $$s/install-sh -c The calls to libtool while installing libffi.la and other files work properly. I believe nothing else is effected and this will simply run as the shell of the installer process. As long as this is /bin/ksh or bash then it seems to behave properly. Hope this helps. Richard rlw at cinci dot rr dot com wrote: >PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11408 > > > >------- Additional Comments From rlw at cinci dot rr dot com 2003-07-22 02:57 ------- >Subject: Re: installation fails for many target libraries > using CONFIG_SHELL > >When looking at the Makefile though the $INSTALL value is not relative. >It is fully qualified, unless I'm looking in the wrong spot. There seem >to only be a few places where libtool is actually called out such as >libstdc++-v3/libffi or libjava. Here is an example of the value of >$INSTALL as set in the Makefile for sparc-sun-solaris2.7/sparcv9/libjava: > >INSTALL = /bin/ksh /export/apps/software_orig/gcc/gcc-3.3/install-sh -c > > >Notice the /bin/ksh in front of the call to install-sh. This seems to >work just fine when $INSTALL is referenced directly, but when it is >called by libtool it crashes with a libtool error. > >pme at gcc dot gnu dot org wrote: > > > >>PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. >> >>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11408 >> >> >> >>------- Additional Comments From pme at gcc dot gnu dot org 2003-07-22 00:58 ------- >>The gcc subdirectory doesn't use libtool to install binaries like "g++". And >>that's one of the files that can't be installed because a relative $INSTALL >>points to a real file only at the top of the build tree. >> >> >> >> >>------- You are receiving this mail because: ------- >>You are on the CC list for the bug, or are watching someone who is. >> >> >> >> >> > > > > > >------- You are receiving this mail because: ------- >You are on the CC list for the bug, or are watching someone who is. > > >
Is there anything we can safely do on the 3.3 branch as this point? If no, I propose to bump the target to 3.4.
*shrug* I think 3.3 is just floundering. The bug is fixed in 3.4. For 3.3, the user just needs to take more care. Invoke configure only using an absolute path, set CONFIG_SHELL appropriately, try and use a better shell.
Fixed in GCC 3.4, workaround documented for GCC 3.3.x
*** Bug 11273 has been marked as a duplicate of this bug. ***