This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: bootstrap fails on Tru64
- From: Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>
- To: Dave Love <d dot love at dl dot ac dot uk>
- Cc: bug-gcc at gnu dot org
- Date: 19 Aug 2002 14:07:05 +0200
- Subject: Re: bootstrap fails on Tru64
- References: <rzqelcvjcoz.fsf@albion.dl.ac.uk>
Dave Love <d.love@dl.ac.uk> writes:
> `make bootstrap' for gcc 3.2 on Tru64 5.1a fails thus, though gcc 3.1
> built OK:
>
> stage1/xgcc -Bstage1/ -B/usr/local/alphaev67-dec-osf5.1/bin/ -DIN_GCC -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H -o cc1 \
> c-parse.o c-lang.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-format.o c-semantics.o c-objc-common.o libcpp.a main.o libbackend.a ./intl/libintl.a -liconv ../libiberty/libiberty.a
> libiconv
> libiconv_open
> libiconv_close
> collect2: ld returned 1 exit status
> gmake[2]: *** [cc1] Error 1
[...]
> I can't immediately see what's going on, i.e. where those symbols with
> the `lib' prefix have come from. Any ideas what to check? It may be
> relevant that the system has libiconv in /usr/local from the
> Compaq-packaged Gnome stuff:
Do you happen to bootstrap with a gcc installed in /usr/local/bin? In that
case, the bootstrap compiler will look in /usr/local/lib and thus configure
will find libiconv there. If the compiler currently being bootstrapped
doesn't look in the same place, stage1/xgcc won't find libiconv and you get
the link failure you describe.
Rainer