Re: java/2812: Build failure; missing symbols (iconv) in link of jc1

Re: java/2812: Build failure; missing symbols (iconv) in link of jc1

[tromey]

Synopsis: Build failure; missing symbols (iconv) in link of jc1

Responsible-Changed-From-To: unassigned->tromey
Responsible-Changed-By: tromey
Responsible-Changed-When: Thu Jun  7 15:52:58 2001
Responsible-Changed-Why:
    I'm handling it.
State-Changed-From-To: open->analyzed
State-Changed-By: tromey
State-Changed-When: Thu Jun  7 15:52:58 2001
State-Changed-Why:
    I don't understand how you could see what you are seeing.
    
    In lex.c, the use of iconv() is predicated on `HAVE_ICONV'.
    This in turn is defined only if configure detects
    `iconv'.  It uses a link test to do this.  So this means
    (to me) that your libc does have iconv().
    
    Maybe your iconv.h redefines iconv() to libiconv()?
    That is what the error messages imply.  But then wouldn't
    this be a bug in your system?
    
    Is your system typical of Alpha Linux systems?
    If so then working around this problem might be appropriate.
    If you're running an unusual system then I'd prefer we just
    leave it.
    
    Tell me what you think and/or discover...
    Thanks!

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2812&database=gcc

Re: java/2812: Build failure; missing symbols (iconv) in link of jc1

[tromey]

Synopsis: Build failure; missing symbols (iconv) in link of jc1

State-Changed-From-To: analyzed->closed
State-Changed-By: tromey
State-Changed-When: Wed Jul 18 10:02:25 2001
State-Changed-Why:
    I've checked in a patch which fixes this problem.
    Can you test it?  I tried it using libiconv on Solaris,
    so I do believe it works.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2812&database=gcc

Re: java/2812: Build failure; missing symbols (iconv) in link of jc1

[Tom Tromey]

The following reply was made to PR java/2812; it has been noted by GNATS.

From: Tom Tromey <tromey@redhat.com>
To: Dave Gilbert <gilbertd@treblig.org>
Cc: gcc-gnats@gcc.gnu.org, gcc@treblig.org
Subject: Re: java/2812: Build failure; missing symbols (iconv) in link of  jc1
Date: 13 Jun 2001 15:51:18 -0600

 >>>>> "Dave" == Dave Gilbert <gilbertd@treblig.org> writes:
 
 Dave> So all I can presume is that whatever happened during the test
 Dave> had LIBICONV_PLUG defined or picked up something else.
 
 The test to see if iconv() is available is a simple link test.  The
 test doesn't include any headers.  So this can't explain what we're
 seeing.
 
 You can see the results of compilation and link tests that configure
 runs.  The output is stored in a file called `config.log' (in the
 `gcc' build directory).
 
 If this approach to iconv is very common we can easily accomodate it.
 We can add an additional test to see if -liconv exists.  Or we can add
 a test to see if a compile with `#include <iconv.h>' can use
 `iconv_open' and still link.  (Or ... almost anything.)
 
 
 I'm guessing that your system has iconv() in libc, but your <iconv.h>
 is from a different package and conflicts with it.  We don't expect
 this, since this is broken.
 
 I have no way to test any fix I might write.  However I could write a
 simple configure.in patch and send it to you if you would test it.
 Still, I'm reluctant to do this if your machine is the only one with
 this configuration.  That would be pointless...
 
 Tom

java/2812: Build failure; missing symbols (iconv) in link of jc1

[gcc]

>Number:         2812
>Category:       java
>Synopsis:       Build failure; missing symbols (iconv) in link of jc1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun May 13 05:26:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Dave Gilbert
>Release:        current Gcc 3 branch cvs (as of 12 May 2001)
>Organization:
>Environment:
Linux/Alpha, libc 2.1.2
>Description:
When doing a make bootstrap on my Linux/Alpha installation the
jc1 build fails with a number of missing symbols from the iconv library
(see below).  I think the issue might be that older libc's don't have
iconv in, but have an external iconv library.

stage1/xgcc -Bstage1/ -B/home/dg/egcs/alphaev56-unknown-linux-gnu/bin/  -DIN_GCC    -g -O2 -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/jcf-parse.o java/mangle.o java/mangle_name.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 mkdeps.o toplev.o libbackend.a -L../zlib -lz obstack.o         ../libiberty/libiberty.a
java/parse.o: In function `java_new_lexer':
java/parse.o(.text+0x7c0): undefined reference to `libiconv_open'
java/parse.o(.text+0x7c4): undefined reference to `libiconv_open'
java/parse.o(.text+0x8a0): undefined reference to `libiconv_open'
java/parse.o(.text+0x8a4): undefined reference to `libiconv_open'
java/parse.o(.text+0x90c): undefined reference to `libiconv'
java/parse.o(.text+0x910): undefined reference to `libiconv'
java/parse.o(.text+0x92c): undefined reference to `libiconv_close'
java/parse.o(.text+0x930): undefined reference to `libiconv_close'
java/parse.o: In function `java_destroy_lexer':
java/parse.o(.text+0xa24): undefined reference to `libiconv_close'
java/parse.o(.text+0xa28): undefined reference to `libiconv_close'
java/parse.o: In function `java_read_char':
java/parse.o(.text+0xd10): undefined reference to `libiconv'
java/parse.o(.text+0xd14): undefined reference to `libiconv'
collect2: ld returned 1 exit status
>How-To-Repeat:

>Fix:
I added -liconv to the link line and it built.
>Release-Note:
>Audit-Trail:
>Unformatted: