Bug 6930 - Both GLIBC_2.0 and GLIBC_2.1 suffixes for some APIs
Both GLIBC_2.0 and GLIBC_2.1 suffixes for some APIs
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
http://x26.deja.com/getdoc.xp?AN=5465...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-11-11 11:37 EST by gk4
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-01-04 18:58:42 EST
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 gk4 1999-11-11 11:37:14 EST
The LSB is trying to inventory the APIs and libraries used
by commercial applications such as StarOffice51 and
WordPerfect8; however, while extracting APIs from the
applications I am having a hard time matching some of them
up within the libraries, because on RedHat 6.0 some of the
APIs have two entries with a "GLIBC_2.0" or "GLIBC_2.1"
suffix.

I have been trying to figure out how the application retains
the information as to which API/suffix it should resolve to
at runtime.   Does anyone have any ideas or a recommendation
as to who I should ask?

+ nm -u -D /usr/local/netscape/netscape | grep fclose
fclose

+ ldd /usr/local/netscape/netscape | grep libc
	libc.so.6 => /lib/libc.so.6 (0x401ac000)

+ nm -g /lib/libc.so.6 | grep fclose
000509f0 T _IO_fclose@@GLIBC_2.1
00053540 T _IO_fclose@GLIBC_2.0
000509f0 T fclose@@GLIBC_2.1
00053540 T fclose@GLIBC_2.0
00052fec W fcloseall

+ rpm -qif /lib/libc.so.6
Name        : glibc   Relocations: (not relocateable)
Version     : 2.1.1   Vendor: Red Hat Software
Release     : 6       Build Date: Fri Apr 16 17:50:24 1999
Install date: Wed Sep 15 16:33:53 1999      Build Host:
porky.devel.redhat.com
Group       : System Environment/Libraries   Source RPM:
glibc-2.1.1-6.src.rpm
Size        : 26821530    License: LGPL
Packager    : Red Hat Software
<http://developer.redhat.com/bugzilla>
Summary     : GNU libc
Description :
Contains the standard libraries that are used by multiple
programs on
the system. In order to save disk space and memory, as well
as to
ease upgrades, common system code is kept in one place and
shared between
programs. This package contains the most important sets of
shared libraries,
the standard C library and the standard math library.
Without these, a
Linux system will not function. It also contains national
language (locale)
support and timezone databases.

George (gk4)
Comment 1 Bill Nottingham 1999-11-11 15:09:59 EST
This is the symbol versioning used in glibc >= 2.1.
For example, a foo@@GLIBC_2.0 is the glibc-2.0 version of
a function, while foo@@GLIBC_2.1 is the glibc-2.1 version.

The symbol matching is done at build time. For example, if
you do objdump -p on a glibc-2.1 binary, you'll get:

Dynamic Section:
  NEEDED      libBrokenLocale.so.1
  NEEDED      libXt.so.6
  NEEDED      libSM.so.6
  NEEDED      libICE.so.6
  NEEDED      libXmu.so.6
  NEEDED      libXpm.so.4
  NEEDED      libXext.so.6
  NEEDED      libX11.so.6
  NEEDED      libdl.so.2
  NEEDED      libstdc++-libc6.1-1.so.2
  NEEDED      libm.so.6
  NEEDED      libc.so.6

as the required libraries, and:

Version References:
  required from libBrokenLocale.so.1:
    0x0d696910 0x00 07 GLIBC_2.0
  required from libdl.so.2:
    0x0d696911 0x00 08 GLIBC_2.1
    0x0d696910 0x00 05 GLIBC_2.0
  required from libm.so.6:
    0x0d696911 0x00 06 GLIBC_2.1
    0x0d696910 0x00 03 GLIBC_2.0
  required from libc.so.6:
    0x0d696911 0x00 04 GLIBC_2.1
    0x0d696910 0x00 02 GLIBC_2.0

as the required versions of those libraries. This says that this binary,
for example, uses both glibc-2.1 and glibc-2.0 interfaces to libc.

Binaries that have no symbol versioning are mapped to the glibc-2.0
interfaces (since glibc-2.0 had no symbol versioning.)

Does that help?



get something like:
Comment 2 Cristian Gafton 2000-01-04 18:58:59 EST
These symbols are normal - it is part of the symbol versioning implemented in
glibc 2.1

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