This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tru64 5.1 bootstrap fails with missing symbols: libiconv et al.


Dara Hazeghi writes:

> I see! Looking at config.log, I see...
> 
> configure:4104: checking for working vfork
> configure:4294: checking for iconv
> configure:4312: cc -o conftest -g   conftest.c  1>&5
> ld:
> Unresolved:
> iconv_open
> iconv
> iconv_close
> configure: failed program was:
> #line 4302 "configure"
> #include "confdefs.h"
> #include <stdlib.h>
> #include <iconv.h>
> int main() {
> iconv_t cd = iconv_open("","");
>        iconv(cd,NULL,NULL,NULL,NULL);
>        iconv_close(cd);
> ; return 0; }
> configure:4334: cc -o conftest -g   conftest.c  
> -liconv 1>&5
> configure:4355: checking for iconv declaration
> configure:4380: cc -c -g  conftest.c 1>&5
> configure:4418: checking whether getenv is declared
> 
> So what I don't understand is that the test obviously
> failed, yet its still trying to link...

No, only the first test (linking a test program using iconv functions
without any additional library) failed, the second one (adding -liconv to
the compilation) succeeded.  config.log with autoconf 2.13 is terrible,
since you cannot see the results of the various tests there.

> I see, there's a GNU libiconv in /usr/local.

... and the default local-prefix is /usr/local, so
/usr/local/include/iconv.h is found during stage2.  This gets you the
references to the alternative names used by GNU libiconv (libiconv_open
instead of iconv_open), but -liconv still links the vendor library which
only provides the iconv_open form ;-(

> Adding it to INTLLIBS seems to get me past that
> failure point. I'll continue bootstrapping...

Indeed, now you using matching headers and libraries.

> Does Zack's work on mainline help with this problem at
> all? Right now it seems ...unintuitive... :-) But if

No, it only made things worse ;-(  Before, you only needed libiconv for the
java compiler, now everything is linked with libiconv.  I used to add
-I/vol/gnu/include to java-warn as a hack to have it effective for java
only, but now it needs to be pushed up to ALL_CPPFLAGS.

> you don't have GNU libiconv installed, this problem
> shouldn't happen, right (bootstrapping on a clean
> system should work)?

I suppose so, yes.

> Well, I take issue with the _clearly_ part. It says
> you need to use -oldas, but immediately after talks

No, it says you need to use the old assembler.

> about using Compaq's C compiler. I took that to mean
> that when using Compaq's compiler, you'd need this
> option. From what you say above, this isn't so?

Certainly not, that's why I had provide the examples:

To bootstrap GCC, you either need to use the Compaq C Compiler:

        % CC=cc srcdir/configure [options] [target]
     
or you can use a copy of GCC 2.95.3 or higher built on Tru64 UNIX V4.0:

        % CC=gcc -Wa,-oldas srcdir/configure [options] [target]

But you are right, this could use some clarification.  The current version
was useful in the GCC 3.0/3.1 days, when the only existing versions of gcc
were hacked (generally broken) copies of 2.95, or binaries from V4.0
systems.  Now that you have a native V5.1 gcc, this complication doesn't
arise any more for most people.

	Rainer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]