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

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

[Jim Wilson]

In article <01BE21FF.058C7220.pedwards.cygnus.egcs@ball.com> you write:
>21331:./conftest: rld: Error: unresolvable symbol in 
>/usr/lib32/libiflPNG.so: __vtbl__9type_info

This happens in texinfo configure.  It looks for and finds a -lz library,
but it is apparently not the -lz library it was expecting to find.  It then
uses it when compiling test programs.  This is mostly harmless, except that
one case (mmap) tries to run the test program, and we end up with error
messages from the run-time linker (rld) that are printed where the user
can see them, instead of put in the config.log file.  The end result is that
configure decides that mmap doesn't work, which is OK.

rld writes to /dev/tty according to the man page, so we probably can't fix
that.

>The build seemed to work, 
>but another executable failed during the make-install, when the .info files 
>were being created (blech).

I am guessing here that the failed program is makeinfo.  I probably didn't
see this because I didn't try to do a make-install.  This is perhaps related
to the -lz configure problem.  It shouldn't be too hard to fix this.  This
problem doesn't prevent us from using `cc -n32' for bootstrapping gcc, it is
just a bug that has to be fixed.

Jim

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

[Zack Weinberg]

On Mon, 7 Dec 1998 15:00:37 -0800, Jim Wilson wrote:
>In article <01BE21FF.058C7220.pedwards.cygnus.egcs@ball.com> you write:
>>21331:./conftest: rld: Error: unresolvable symbol in 
>>/usr/lib32/libiflPNG.so: __vtbl__9type_info
>
>This happens in texinfo configure.  It looks for and finds a -lz library,
>but it is apparently not the -lz library it was expecting to find.  It then
>uses it when compiling test programs.

Which IRIX is this?  The only sgi box I have access to doesn't have
any -lz library.

The configure check for libz *seems* basically sane, it looks for the
header and for a function in the library before concluding it works.
Maybe this IRIX ships with a broken version of the right library, and
we should add a check for that.

zw

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

[Jim Wilson]

	Which IRIX is this?  The only sgi box I have access to doesn't have
	any -lz library.

irix6.3.

Look in /usr/lib32.  That is where the N32 libraries are.  If you look in
/usr/lib you won't find it.  /usr/lib has only O32 libraries, and there is
no O32 -lz library.

	Maybe this IRIX ships with a broken version of the right library, and
	we should add a check for that.

There was mail from Lee Iverson explaining that it is buggy.
See < http://www.cygnus.com/ml/egcs/1998-Dec/0250.html >.

Jim

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

[Marc Espie]

In article < 199812072300.PAA13084@rtl.cygnus.com > you write:

>This happens in texinfo configure.  It looks for and finds a -lz library,
>but it is apparently not the -lz library it was expecting to find.  It then
>uses it when compiling test programs.  This is mostly harmless, except that
>one case (mmap) tries to run the test program, and we end up with error
>messages from the run-time linker (rld) that are printed where the user
>can see them, instead of put in the config.log file.  The end result is that
>configure decides that mmap doesn't work, which is OK.


Misdetection of -lz by texinfo's configure has been a pain for a long time
now...  this fucker tends to find it everywhere and nowhere, mismanage the
link line, and forget whatever options are needed, like finding it with -L,
but not even checking whether -R or something is *required* for linking 
with it.

Personally, I tend to get and install texinfo separately, then delete
the texinfo directory from any egcs distribution I get as soon as I can.

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

[Phil Edwards]

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

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

[Lee Iverson]

In message < 01BE22B5.C449D2F0.pedwards@ball.com > you write:
> 
> 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.

I'm a fan, but this is really an egcs problem (without an obvious
fix).  egcs is trying to do a full multilib build but without first
testing that it can do it.  Most SGI users don't *ever* build -64
programs and thus don't even install any of the -64 libraries or
support software.  Yet, egcs doesn't check this before deciding that
it should build -64 multilib versions...

The short answer is that you need to install (at least)
compiler_eoe.sw64.lib from the Development Libraries CD.  Ideally
there'd be a way of selecting multilib variations to compile at the
`configure' level of egcs.

-------------------------------------------------------------------------------
Lee Iverson     		SRI International
leei@ai.sri.com			333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/	(650) 859-3307

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

[Jim Wilson]

In article <199812081926.LAA08225.cygnus.egcs@canada.ai.sri.com> you write:
>Ideally
>there'd be a way of selecting multilib variations to compile at the
>`configure' level of egcs.

The configure option --disable-multilib should build only the default (N32)
librarires.  I haven't tested it in a long time though.

Jim

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

[Phil Edwards]

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

I tried the bootstrap anyhow, out of curiosity.  The build seemed to work, 
but another executable failed during the make-install, when the .info files 
were being created (blech).  I scrapped that build.


I am trying a bootstrap now using cc -32.


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

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

[Lee Iverson]

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