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

Russ Allbery rra@stanford.edu
Fri Jul 18 17:20:00 GMT 2003


Dara Hazeghi <dhazeghi@yahoo.com> writes:

> Hello,

> 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:

> 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? 

You're probably picking up the Tru64 libiconv instead of the GNU libiconv.
Tru64 has an interesting library search algorithm where it looks for the
shared versions of libraries along the entire search path before it looks
for the static versions anywhere, so if you have GNU libiconv installed
static it will still find the system libiconv (which is shared) even if
it's later in the library search path.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the Gcc-bugs mailing list