[4917] in testers
Re: possible compatibility issues in g++ between Athena 8.4 and 9.0
daemon@ATHENA.MIT.EDU (Larry Stone)
Wed Jun 27 21:26:42 2001
Date: Wed, 27 Jun 2001 21:26:38 EDT
From: Larry Stone <lcs@MIT.EDU>
Reply-To: <lcs@MIT.EDU>
To: Alex T Prengel <alexp@MIT.EDU>
Cc: testers@MIT.EDU, alexp@MIT.EDU, gnu@MIT.EDU
In-Reply-To: Your message of Wed, 27 Jun 2001 11:39:42 -0400
Message-ID: <CMM.0.90.4.993691598.lcs@defiant.mit.edu>
Summary: it's fixed, try again Thursday.
> 2. When I try to run the binary built in 1. on Athena 9.0, I get:
>
> fatal: libstdc++.so.2.10.0: open failed: No such file or directory
The Sun ld, which we have to use on Solaris 8 because even the latest
GNU binutils have known bugs there, seems to have the executable load
this shared object even though there aren't any references to it.
I first got it to work by extracting the commands generated by the link
phase of the compiler and manually picking out the -lstdc++ and observing
the resulting binary worked fine. (that is, if it's supposed to
generate a big ugly round purple thing looking like a starship's-eye-view
of a wormhole.)
Disabling the shared objects for libstdc++ also has the desired
effect, and that seems to be what was done on other platforms.
So, I've done this for the Solaris 8 architecture. Changes should
take effect by Thursday, please try the build again.
(I confirmed this by building the medical1 [yuck!] demo as well.)
You'll still get the ominous "malformed string table, initial or final byte"
messages but ld can apparently get past them and produce a usable binary.
It would still be best to rebuild the vtk libraries for the solaris 8
platform, since that has gcc 2.95.3 instead of 2.95.2 and gcc had to be
configured to use the vendor "ld" on Solaris 8 while it uses GNU ld on
Solaris 7. I suspect that is why ld complains about those libraries.
Thanks for providing a simple and easy test case.
-- Larry
