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

[Rainer Orth <ro at TechFak dot Uni-Bielefeld dot DE>]

Dara Hazeghi <dhazeghi@yahoo.com> 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
> libiconv
> libiconv_open
> libiconv_close
> 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
gcc/Makefile.

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
  warns

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.

	Rainer