../gcc-3.3-20030506/configure --prefix=$DEST/gcc-3.3-20030506 --with-local-prefix=$DEST/gcc-3.3-20030506 --with-gnu-ld --with-ld=$NEWBINBIN/gld --with-gnu-nm --with-nm=$NEWBINBIN/gnm --with-gnu-as --with-as=$NEWBINBIN/gas --enable-threads=posix --enable-shared --enable-languages=all --disable-nls make bootstrap ../../gcc-3.3-20030506/gcc/java/jcf-path.c -o java/jcf-path.o stage1/xgcc -Bstage1/ -B/proj/wdt/gnu_sun5.8/gcc-3.3-20030506/sparc-sun-solaris2.8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijav a -I../../gcc-3.3-20030506/gcc -I../../gcc-3.3-20030506/gcc/java -I../../gcc-3.3-20030506/gcc/config -I../../gcc-3.3-20030506/gcc/../include ../../gcc-3.3-20030506/gcc/java/xref.c -o java/xref.o stage1/xgcc -Bstage1/ -B/proj/wdt/gnu_sun5.8/gcc-3.3-20030506/sparc-sun-solaris2.8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijav a -I../../gcc-3.3-20030506/gcc -I../../gcc-3.3-20030506/gcc/java -I../../gcc-3.3-20030506/gcc/config -I../../gcc-3.3-20030506/gcc/../include ../../gcc-3.3-20030506/gcc/java/boehm.c -o java/boehm.o stage1/xgcc -Bstage1/ -B/proj/wdt/gnu_sun5.8/gcc-3.3-20030506/sparc-sun-solaris2.8/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -I. -Ijav a -I../../gcc-3.3-20030506/gcc -I../../gcc-3.3-20030506/gcc/java -I../../gcc-3.3-20030506/gcc/config -I../../gcc-3.3-20030506/gcc/../include \ -DINLINER_FOR_JAVA=1 \ ../../gcc-3.3-20030506/gcc/tree-inline.c -o java/java-tree-inline.o rm -f jc1 stage1/xgcc -Bstage1/ -B/proj/wdt/gnu_sun5.8/gcc-3.3-20030506/sparc-sun-solaris2.8/bin/ -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long- long -DHAVE_CONFIG_H -o jc1 \ java/parse.o java/class.o java/decl.o java/expr.o java/constants.o java/lang.o java/typeck.o java/except.o java/verify.o java/zextract.o java/jcf-io.o java/win32-host.o java/jcf-parse.o java/mangle.o java/mangle_name.o java/builtins.o java/jcf-write.o java/buffer.o java/check-init.o java/jcf-depend.o java/jcf-path.o java/xref.o java/boehm.o java/java-tree-inline.o mkdeps.o main.o libbackend.a -L../zlib -l z -liconv ../libiberty/libiberty.a /proj/wdt/gnu_sun5.8/binutils-2.13.2.1/bin/gld: cannot find -liconv collect2: ld returned 1 exit status make[2]: *** [jc1] Error 1 make[2]: Leaving directory `/proj/wdtold/warrend/gnusrc/gcc-3.3-20030506/gcc-3.3-20030506_sun5.8/gcc' make[1]: *** [stage2_build] Error 2 make[1]: Leaving directory `/proj/wdtold/warrend/gnusrc/gcc-3.3-20030506/gcc-3.3-20030506_sun5.8/gcc' make: *** [bootstrap] Error 2 Release: unknown How-To-Repeat: Configre as shown make bootstrap I don't think it should be using libiconv since I did --disable-nls. If it should it didn't put a -L to find it. This didn't do this in 3.2.3
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, mark@codesourcery.com, nobody@gcc.gnu.org, warren.dodge@tek.com, gcc-prs@gcc.gnu.org Cc: Subject: Re: bootstrap/10657: java section can not find ;ibiconv Date: Wed, 7 May 2003 15:52:40 +0200 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10657 I just bootstrapped the prerelease tarball successfully on a SunOS theseus 5.9 Generic_112233-03 sun4u sparc SUNW,Ultra-4 with the following configure command: /home/thales/ehrhardt/gcc-3.3/gcc-3.3-20030506/configure --disable-nls \ --with-ld=/usr/local/bin/ld --with-as=/usr/local/bin/as --with-gnu-ld \ --with-gnu-as --prefix=/home/thales/ehrhardt/gcc-3.3/install I'm now bootstrapping with native tools, testsuite results won't be availiable before Friday. Note: There was one minor problem when bootstrapping at -j4 that went away after I restarted the bootstrap. This is probably a missing dependancy somewhere. regards Christian -- THAT'S ALL FOLKS!
From: Jeff Sturm <jsturm@one-point.com> To: gcc-gnats@gcc.gnu.org, <gcc-bugs@gcc.gnu.org>, <mark@codesourcery.com>, <warren.dodge@tek.com> Cc: Subject: Re: bootstrap/10657: java section can not find ;ibiconv Date: Wed, 7 May 2003 18:53:02 -0400 (EDT) In the root of your failing build tree, can you run grep iconv config.cache and paste the output? In particular, I'm interested in am_cv_func_iconv, am_cv_lib_iconv and am_cv_lib_iconv_ldpath. I could not reproduce this problem on my Solaris 8 machine yet. Moreover, Solaris 8 does not have a separate libiconv, it is integrated with libc. I'm guessing your problem may occur if all the following are true: a) Your bootstrap compiler is GCC and lives in a different --prefix than that you are configuring for b) GNU libiconv is installed in the same prefix as your bootstrap compiler c) libiconv is not available in /usr/lib or one of the system search paths Jeff
From: "Christian Ehrhardt" <ehrhardt@mathematik.uni-ulm.de> To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, mark@codesourcery.com, nobody@gcc.gnu.org, warren.dodge@tek.com, gcc-prs@gcc.gnu.org Cc: Subject: Re: bootstrap/10657: java section can not find ;ibiconv Date: Thu, 8 May 2003 11:59:34 +0200 On Wed, May 07, 2003 at 03:52:40PM +0200, Christian Ehrhardt wrote: > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10657 > > I just bootstrapped the prerelease tarball successfully on a > > SunOS theseus 5.9 Generic_112233-03 sun4u sparc SUNW,Ultra-4 Testsuite resulte are at http://gcc.gnu.org/ml/gcc-testresults/2003-05/msg00485.html regards Christian -- THAT'S ALL FOLKS!
Responsible-Changed-From-To: unassigned->jsturm Responsible-Changed-Why: I'll take it.
State-Changed-From-To: open->analyzed State-Changed-Why: There are two distinct aspects of this PR: - why does the bootstrap fail - why does jc1 need iconv when configured with --disable-nls The first is a consequence of bootstrapping from a gcc compiler coninstalled with GNU libiconv. I don't know how to fix it easily, since configuration and libiconv detection is performed with the bootstrap compiler, not the stage1 compiler. Nevertheless the problem should be documented. For the second, it's debateable whether jc1 should try to use -liconv in this case. The Java language requires Unicode support. One option is to not build the java frontend at all with --disable-nls.
I'd guess the best way to handle this bug is to reconfigure after stage1. For that it would probably be best to wait for Nathaniel's toplevel bootstrap patches. Meanwhile, as a workaround you can configure --with-libiconv-prefix=<directory> where <directory> contains ./include/iconv.h and ./lib/libiconv.{a,so}.
This looks like this not never be fixed for 3.3.x, right?
Subject: Re: [3.3 regression] java section can not find libiconv As far as I know this was not fixed. I tried building gcc-3.3-20030508 and had the problem. I haven't touched it since then. I also submitted another enhancement request that would solve this problem. It was to allow us to specify a "library/include directory" which would be pushed down through the process of making gcc and become part of the "specs" file also. This would be similar to the libiconv switch but more general.
Toplevel bootstrap is not going in for 3.4, so this is not mine ATM.
Not a bug, set LD_LIBRARY_PATH right.
Subject: Re: [3.3 regression] java section can not find libiconv My goal in life is to never set LD_LIBRARY_PATH. I have anyone of hundreds of people who may use what I build. I would like only to say run /path/bin/gcc rather then set some number of environment variables which may break other things that they are doing. I have had a terrible time in getting bootstrapped on Solaris 2.5.1 and Solaris 8. I have no access as ROOT or to /usr/local on these systems. It sure would be useful if someone could write up a procedure on how to 1. start with a downloaded precompiled binary or Sun's compiler. 2. Build a gcc/binutils/libiconv/gettext that resides somewhere other then /usr/local, find the libraries mentioned in step3, and require no special environment variables to be set. This combination is interesting since there is dependancies in multiple directions. 3. Build other library modules (ncurses,zlib,db, etc) and install them in a central location that gcc knows about. I would rather do this then put stuff into gcc's tree to prevent breaking it accidently. The instructions in the installation notes seem only to work properly if there is a system of gnu software installed already.
Sorry but you will need to set LD_LIBRARY_PATH unless you add -R to all your compiling of your programs in the nonstandard path.
(In reply to comment #13) > Sorry but you will need to set LD_LIBRARY_PATH unless you add -R to all your compiling of your > programs in the nonstandard path. Andrew, I think there is a valid complaint here, though it will not be fixed for 3.4, and is probably not a regression either. configure is detecting and using libiconv based on the bootstrap compiler's settings. This fails in stage2 when the bootstrap compiler is no longer used. There are workarounds, you mentioned LD_LIBRARY_PATH and -R. Or uninstall libiconv from the bootstrap compiler's path. Or install it first in ${prefix}. Nevertheless it's bogus of configure to do this, and completely preventable when bootstrap moves to toplevel (so stage2 can reconfigure following bootstrap). I think it should be kept open, perhaps at lower priority. Is there a PR you know of for toplevel bootstrap? If so, this one could depend on it.
Not really regression.
Closing as won't fix as the Java front-end has been removed from the trunk.