RE: Ugly missing symbols, was Re: egcs, Irix6 linking o32-libiberty.a with n32-stage2/3 binaries ...

[Phil Edwards <pedwards at ball dot com>]

On Monday, December 07, 1998 5:26 PM, Lee Iverson [SMTP:leei@ai.sri.com] 
wrote:
> 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.

In yesterday's message I said I was trying to bootstrap with -32.  Well, it 
failed; not on the compiler, but on building the standard runtime lib.  I'll 
type the last few lines of the build log here; hopefully somebody will 
recognize where this happens (i.e., which Makefile, somewhere, isn't quite 
correct; I tried looking but gcc is just too big for me to understand in one 
sitting).


mv tlist piclist
/usr/local/src/building/here/gcc/xgcc
  -B/usr/local/src/building/here/gcc/
  -g -O2 -fno-implicit-templates -mabi=64 -shared
  -o libstdc++.so.2.9.0 `cat piclist` -lm
ld64: FATAL 9: I/O error (-lm): No such file or directory
collect2: ld returned 32 exit status
gmake[4]:  *** libstd++.so.2.9.0 Error 1


The "target trace" printed back from gmake at this point was 
libstd++.so.2.9.0, multi-do, multi-all, all-target-libstdc++, bootstrap.

Obviously, libm isn't being found.  I discovered it under /usr/lib and 
/usr/lib32, but since -mabi=64 is being specified, the linker searches 
/usr/lib64, which has no libm.*.

(I'm wondering whether specifying CC='cc -n32' was even worth it, given that 
the build process seems to prefer -64.)

God, I hate SGIs.


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

I'll try one or both of these.  Much thanks!

What I'd /really/ like to find is a make target that installs /only/ the 
compiler and runtime libraries; not the documentation.  (The complete install 
is already done on our "public" machine, but now I just need to get a working 
C++ compiler on all of our isolated "I could tell you but I'd have to kill 
you" machines.  We don't need .info files on those.)  I've tried looking 
through the top-level Makefile, but I got dizzy after a few minutes.

Did I mention how much I hate SGIs?


--
pedwards@ball.com    Ball Aerospace & Technologies Corp.
(937-320-4048)       Advanced Systems & Technology Operations