Description of problem: When trying to install the Waterloo Maple (Linux ver 8) I get an error message and it just won't load pointing to an error in the library /lib/tls/libc-2.3.2.so I should add that the same package works well on Red Hat 7.3 but fails on all versions since the /lib/tls directory was introduced. If I rename this file (so that xmaple will not find it) then it (presumably) uses the /lib/libc-2.3.2.so and xmaple then loads OK. However if I do other jobs whilst /lib/tls/libc-2.3.2.so is disabled I find I can mess up my system. I should also inform you that the same Maple package installs and loads fine on Mandrake 9.1 and Suse 8.1. Version-Release number of selected component (if applicable): Waterloo Maple ver 8 (Linux) How reproducible: Always Steps to Reproduce: 1. Install Waterloo Maple ver 8 2. Enter xmaple <return> 3. Actual results: gives error message - sorry can't reproduce it from machine I'm now on. Maple fails to open its opening window. Expected results: Additional info:
If the error is like relocation error: XYZ: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference or Incorrectly built binary which accesses errno or h_errno directly. Needs to be fixed. then it is a Mapple bug which Mapple needs to fix. You can work around it by running it with LD_ASSUME_KERNEL=2.4.19 (see release notes). If it is a different error, you need to specify what exactly.
The precise error message I get is as below (pasted from output): /arcs/maple8/bin.IBM_INTEL_LINUX/mserver: relocation error: /arcs/maple8/bin.IBM_INTEL_LINUX/libmaple.so: symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference It seems odd to me that you claim the bug is in the Maple program, widely used by Mathematicians worldwide and which appears to work OK with other distros with kernels later than 2.4.19.
If it is a library linked against glibc 2.1 and later (you can find this out by readelf -V /arcs/maple8/bin.IBM_INTEL_LINUX/libmaple.so | grep GLIBC_2 ), having errno in the symbol table is a bug (source uses errno yet doesn't #include <errno.h> as standards mandate). And given that ld.so complains about errno@@GLIBC_2.0, not plain errno suggest that it is a glibc 2.1+ compiled library (glibc 2.0 was not versioned).