This is the mail archive of the
mailing list for the GCC project.
Re: Tru64 5.1 bootstrap fails with missing symbols: libiconv et al.
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- To: Dara Hazeghi <dhazeghi at yahoo dot com>
- Cc: gcc-bugs at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: 18 Jul 2003 19:17:54 +0200
- Subject: Re: Tru64 5.1 bootstrap fails with missing symbols: libiconv et al.
- References: <email@example.com>
Dara Hazeghi <firstname.lastname@example.org> writes:
> I just tried bootstrapping current 3.3 branch
> (20030717) on Tru64 5.1B. Bootstrap fails in stage2
> linking gcov. This configuring without any additional
> flags (besides --prefix) and using Compaq C to build
> the stage1 compiler:
What --prefix did you use. Is this an empty directory, or is any software
installed there? What was the exact configure line used?
> stage1/xgcc -Bstage1/
> -B/tmp/gcc33/alphaev68-dec-osf5.1/bin/ -g -O2
> -DIN_GCC -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wtraditional
> -pedantic -Wno-long-long -DHAVE_CONFIG_H -o cc1 \
> c-parse.o c-lang.o c-pretty-print.o attribs.o
> c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o
> c-convert.o c-aux-info.o c-common.o c-opts.o
> c-format.o c-semantics.o c-objc-common.o c-dump.o
> libcpp.a main.o libbackend.a ./intl/libintl.a
> -liconv ../libiberty/libiberty.a
> collect2: ld returned 1 exit status
> Strange thing is that the libiconv is being linked
> against... Any ideas? Thanks,
Sure: this libiconv stuff is currently a terrible mess ;-( Do you happen
to have GNU libiconv installed in $prefix?
This regularly happens for me in the following situation:
* I start bootstrap with gcc 3.1 installed in the same directory hierarchy
as GNU libiconv, so the bootstrap compiler finds and uses it.
* The new compiler uses a different $prefix, and doesn't search the
bootstrap compiler's hierarchy. While during stage1, GNU libiconv and
it's iconv.h were used, stage2 uses the system iconv.h and libiconv,
which doesn't provide the libiconv_* functions.
My hacky workaround is to add -L<libiconv dir> to LIBICONV in gcc/Makefile,
and -isystem (or -I if the bootstrap compiler isn't gcc) to ALL_CPPFLAGS in
In theory, --with-libiconv-prefix=DIR should be able to handle this, but
doesn't for three reasons:
* It adds -I DIR/include to CPPFLAGS during configure. If the bootstrap
compiler is an old version of gcc, configured with $prefix = DIR, it
cc1: warning: changing search order for system directory "/vol/gnu/include"
cc1: warning: as it has already been specified as a non-system directory
which causes several unrelated configure tests to fail. This needs to be
made more intelligent: if the bootstrap compiler is (a sufficiently
recent, I don't know when -isystem got added?) version of gcc, -isystem
should be used instead of -I.
* While configure sets CPPFLAGS to DIR/include with this flag, this
CPPFLAGS value isn't substituted anywhere in gcc/Makefile and thus lost.
It should be added to ALL_CPPFLAGS.
* Even if -L DIR/lib is added to LIBICONV (or LDFLAGS, I'm not sure?), on
many systems you need -R/-rpath so the shared libiconv.so is found at
runtime too. Otherwise, the libiconv users will link, but not run ;-(
config.rpath in gettext/GNU libiconv is expected to deal with this.
As you can see, a terrible mess. I haven't yet gotten around to
properly fixing this.
> P.S. Is the -oldas option still required to bootstrap
> on this platform (as described in install/specific.html)?
Why do you think so? install.texi clearly states that you only need this
if bootstrapping starting from an old version of gcc built for Tru64 UNIX
V4.0. But you are right: if you start bootstrap with a version of GCC
already built properly for Tru64 UNIX V5, this becomes unnecessary.