This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Ugly missing symbols, was Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
- To: "pedwards at ball dot com" <pedwards at ball dot com>
- Subject: Re: Ugly missing symbols, was Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...
- From: Lee Iverson <leei at ai dot sri dot com>
- Date: Mon, 07 Dec 1998 14:25:55 -0800
- cc: "'egcs at egcs dot cygnus dot com'" <egcs at egcs dot cygnus dot com>
In message <01BE21FF.058C7220.pedwards@ball.com> you write:
>
> Jim Wilson:
> > I had trouble bootstrapping egcs with 7.1 (-o32 didn't work
> either), but 7.2
> > has been out for more than a year, and it has not given any
> problem with -n32.
> >
> > I have never seen a problem with cc -32. Perhaps there was something
> > else wrong, e.g. a bug in some other program besides the compiler.
> >
> > I did a bootstrap with SGI C 7.1 yesterday, and didn't run into any
> problems.
> >
> > Jim
>
> I've been having fatal errors bootstrapping under Irix 6.3 using the 7.2
> compiler and CC='cc -n32' for the configure. Looks something like this:
>
> Configuring for a mips-sgi-irix6.3 host.
> Created "Makefile" in /usr/local/src/building/here using "mh-frag"
> 21331:./conftest: rld: Error: unresolvable symbol in
> /usr/lib32/libiflPNG.so: __vtbl__9type_info
> 21331:./conftest: rld: Error: unresolvable symbol in
> /usr/lib32/libiflPNG.so: __T_9__nothrow
> 21331:./conftest: rld: Error: unresolvable symbol in /usr/lib32/libifl.so:
> __pure_virtual_called
> [similar errors snipped]
> 21331:./conftest: rld: Fatal Error: this executable has unresolvable
> symbols
> Links are now set up to build a native compiler for mips-sgi-irix6.3
This has nothing to do with the compiler. It turns out that the SGI
Image Format Library (ifl) is written in C++ with an optional C API.
For some idiotic reason, this shared library is *not* linked with a
reference to the libCsup.so library (SGI CC's version of libgcc.a).
According to SGI support a defect report (which I tried to submit)
wouldn't actually lead to a fix (how hard could it be to relink the
library?), since this is an optional library for which subsequent
(incompatible) versions have been released...
What does this have to do with anything in gcc? Well, makeinfo links
against -lz if it is available, and if you track the system -lz down
it is a link to libiflPNG.so. So when you try to run makeinfo (or for
that manner any C program linked against the system -lz), you get the
error seen above.
One fix is to compile with 'make LIBS=-lCsup'. Another is to add the
following line to texinfo/configure.in just prior to
AC_CHECK_HEADERS(zlib.h,..):
AC_CHECK_LIB(Csup, __T_9__nothrow)
Thus is an ugly enough symbol that it shouldn't impact anyone that
doesn't need it...
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307