Bug 10657 - java section can not find libiconv
Summary: java section can not find libiconv
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
: 9047 10728 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-05-07 05:16 UTC by warren.dodge
Modified: 2005-07-23 22:39 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-04-26 03:54:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description warren.dodge 2003-05-07 05:16:00 UTC
../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
Comment 1 Christian Ehrhardt 2003-05-07 15:52:40 UTC
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!

Comment 2 Jeff Sturm 2003-05-07 18:53:02 UTC
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
 

Comment 3 Christian Ehrhardt 2003-05-08 11:59:34 UTC
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!
Comment 4 Jeff Sturm 2003-05-08 13:58:23 UTC
Responsible-Changed-From-To: unassigned->jsturm
Responsible-Changed-Why: I'll take it.
Comment 5 Jeff Sturm 2003-05-08 13:58:23 UTC
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.
Comment 6 Jeff Sturm 2003-06-08 01:44:43 UTC
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}.
Comment 7 Andrew Pinski 2003-06-11 22:47:33 UTC
This looks like this not never be fixed for 3.3.x, right?
Comment 8 warrend 2003-06-11 23:23:24 UTC
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.





Comment 9 Nathanael C. Nerode 2003-10-24 20:40:41 UTC
Toplevel bootstrap is not going in for 3.4, so this is not mine ATM.
Comment 10 Nathanael C. Nerode 2003-10-24 20:40:52 UTC
Toplevel bootstrap is not going in for 3.4, so this is not mine ATM.
Comment 11 Andrew Pinski 2003-11-19 23:25:51 UTC
Not a bug, set LD_LIBRARY_PATH right.
Comment 12 warrend 2003-11-20 00:19:54 UTC
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. 


Comment 13 Andrew Pinski 2003-11-20 00:31:32 UTC
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.
Comment 14 Jeff Sturm 2003-11-20 03:29:38 UTC
(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.
Comment 15 Andrew Pinski 2004-01-14 04:45:16 UTC
Not really regression.