Tru64 5.1 bootstrap fails with missing symbols: libiconv et al.
Rainer Orth
ro@TechFak.Uni-Bielefeld.DE
Fri Jul 18 18:31:00 GMT 2003
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
More information about the Gcc-bugs
mailing list