Linux undefined symbol: cerr problem and solution

[frmky]

Hello,

I installed Linux on my Opteron, and ran into a problem when trying to run the Linux client. I'm documenting the problem and solution here in case others run into it, and so I'll know what to do if I encounter it again.

After unpacking the client and trying to run nfsnetinit, I got the following error:
./nfsnetinit: relocation error: ./nfsnetinit: undefined symbol: cerr
With ldd, I discovered that the client uses /emul/linux/x86/usr/lib/gcc-lib/i386-pc-linux-gnu/3.2.3/libstdc++-libc6.2-2.so.3 which, in the 32-bit libraries on my machine, was a symlink to libstdc++.so.5.0.3. This did not make nfsnetinit happy.

So, turning to Google, I found compat-libstdc++-7.3-2.96.118 RPM for i386 at http://at.rpmfind.net/opsys/linux/RP....118.i386.html, verified that it does contain the needed library, and downloaded it. Since it's supposed to go into the 32-bit emulation directory, not /usr/lib, I used rpm2targz and extracted everything, deleted the unwanted symlink, copied all the libraries in this package to the directory above, and ran ldconfig. Finally, nfsnetinit is happy.

Greg

[Wacky]

Thanks for the information.

We have a tradeoff here. There is no such thing as a "standard Linux", (or any of the other Un*x variants). To make matters worse, it is difficult to determine which libraries should be supported.

Would it be better to do a static linking, thus bypassing the advantage of a shared library to isolate the underlying OS ( and save real memory as well)?

I must point out that a "source distribution" is not a viable alternative because of licencing problems and the fact that a large number of the participants would not know how to make use of it if it were available.

PS: I need some C++ coding help to get the next major revision set up.

Richard

[frmky]

Speaking of the source, is the line siever all C or does it contain assembly optimizations? If C, I'm curious to see if an AMD64 binary would be any faster. The additional available registers may help. If the current binary contains hand-tuned assembly, though, I'm sure a 64-bit client from C can't beat that.

Greg

[aaronl]

Originally Posted by Wacky

Thanks for the information.

Would it be better to do a static linking, thus bypassing the advantage of a shared library to isolate the underlying OS ( and save real memory as well)?

It might be a good idea to offer a static binary for people with unusual systems. Most people will prefer a dynamic binary because it will use less memory.

C++ makes the situation more a little more complicated. The GCC C++ ABI changed recently. Most systems have compatibility libraries installed, but some don't, for example the Opteron system discussed above which didn't have a 32-bit version of the older C++ standard library.

Another thing worth considering is that if your binaries are using the older ABI, they probably weren't produced by the latest and greatest compiler. nfsnet-04030-x86-Linux seems to have been built by "GCC: (GNU) 2.96 20000731 (Red Hat Linux 7.1 2.96-79)". As you can see from the timestamp, it's somewhat old. GCC 2.96 was not an official release and it has a sort of bad reputation. It can't be that bad if Red Hat made it the system compiler, though. GCC 3.3 does a better job of complying with the C++ standard and generally produces faster and more correct code. Ordinarily I wouldn't care very much, but when dealing with distributed computing projects that run on hundreds of computers for months, people usually are passionate about squeezing every last bit of performance out of the software. I'd think it's worth benchmarking. If you do start using a newer version of gcc, a static version of the binary is even more useful, because it allows people who don't have modern C++ libraries to run the software.

[junky]

Thanks for ur suggestions, i'm sure the NFSnet staff would take ur suggestion and will do it as soon as possible.

Thanks.