Bug 91342 - LTC3752-symbol errno, version GLIBC_2.0 not defined in file libc.so.6
LTC3752-symbol errno, version GLIBC_2.0 not defined in file libc.so.6
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
https://rhn.redhat.com/network/softwa...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-21 12:43 EDT by Aldo A. Duran
Modified: 2016-11-24 09:54 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-21 12:51:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aldo A. Duran 2003-05-21 12:43:55 EDT
Description of problem:

I am participating in the Red Hat Enterprise Linux 3 early
access program.
When I try to install one of our products I got the error:

/data/aduran/41/11023/instdir/bin/linux-ix86/wserver_cli: relocation
error: /data/aduran/41/11023/instdir/iblib/linux-ix86/libtas272b.so:
symbol errno, version GLIBC_2.0 not defined in file libc.so.6
with link time reference

Our product was build on Red Hat 6.2 and it installs and runs
fine in many other releases of Red Hat but not in this new
release (RH ES 3.0).

Looking at both libraries involved here I see the following:

nm /data/aduran/41/11023/instdir/iblib/linux-ix86/libtas272b.so | grep errno
         U errno@@GLIBC_2.0
         U __errno_location@@GLIBC_2.0
         U oerrno_to_exid
         U o_get_errno

ls -l /lib/libc.so.6
lrwxrwxrwx    1 root     root           13 Apr 15 12:16 /lib/libc.so.6 -> libc-
2.3.2.so
readelf -s /lib/libc.so.6 | grep errno | grep OBJECT
  1036: 00136f40     4 OBJECT  GLOBAL DEFAULT   27 _errno@GLIBC_2.0
  1164: 00136f40     4 OBJECT  GLOBAL DEFAULT   27 errno@GLIBC_2.0
  1746: 00138b04     4 OBJECT  GLOBAL DEFAULT   27 h_errno@GLIBC_2.0
  2142: 00138b04     4 OBJECT  WEAK   DEFAULT   27 _h_errno@GLIBC_2.0
  7492: 00136f40     4 OBJECT  GLOBAL DEFAULT   27 _errno@GLIBC_2.0
  7620: 00136f40     4 OBJECT  GLOBAL DEFAULT   27 errno@GLIBC_2.0
  8202: 00138b04     4 OBJECT  GLOBAL DEFAULT   27 h_errno@GLIBC_2.0
  8598: 00138b04     4 OBJECT  WEAK   DEFAULT   27 _h_errno@GLIBC_2.0

The same library from Red Hat 8.0 shows:
ls -l /lib/libc.so.6
lrwxrwxrwx    1 root     root           14 Feb 20 05:50 /lib/libc.so.6 -> libc-
2.2.93.so
readelf -s /lib/libc.so.6 | grep errno | grep OBJECT
   294: 0012932c     4 OBJECT  WEAK   DEFAULT   16 _h_errno@@GLIBC_2.0
   341: 0012d6e0     4 OBJECT  GLOBAL DEFAULT   24 errno@@GLIBC_2.0
   888: 0012932c     4 OBJECT  GLOBAL DEFAULT   16 h_errno@@GLIBC_2.0
  1913: 0012d6e0     4 OBJECT  GLOBAL DEFAULT   24 _errno@@GLIBC_2.0

This is a bug becuase old products will not be able to
run on this release.

you can contact me at: aduran@us.ibm.com

Thanks
aldo


Version-Release number of selected component (if applicable):


How reproducible:
Every time

Steps to Reproduce:
1.Create a program that uses errno in a Red Hat 6.2 
2.Install and run the program on RH ES 3.0
3.
    
Actual results:


Expected results:
Old applications should still run on new servers.

Additional info:
Comment 1 Jakub Jelinek 2003-05-21 12:51:44 EDT
"Old applications should still run on new servers." - yes, unless they are buggy,
which is the case of your product (or some .a library it links in, cannot tell).
The above error is a result of not including <errno.h> when errno is used,
Declaring it byhand is wrong, since errno is allowed to be a macro (and it is
in glibc for the last 7 years).
You can work around the bug by setting LD_ASSUME_KERNEL=2.4.1 in the environment,
which will mean NPTL libc+libpthread will not be used (for them it is impossible
to provide errno@GLIBC_2.0).
Only applications linked against glibc 2.0.x may legally reference errno
symbol (non-versioned), but that is handled by the dynamic linker automatically
(by not using NPTL).

Note You need to log in before you can comment on or make changes to this bug.