Bug 6930 - Both GLIBC_2.0 and GLIBC_2.1 suffixes for some APIs
Summary: Both GLIBC_2.0 and GLIBC_2.1 suffixes for some APIs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
URL: http://x26.deja.com/getdoc.xp?AN=5465...
Depends On:
TreeView+ depends on / blocked
Reported: 1999-11-11 16:37 UTC by gk4
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-04 23:58:42 UTC

Attachments (Terms of Use)

Description gk4 1999-11-11 16:37:14 UTC
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"

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

+ 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
000509f0 T fclose@@GLIBC_2.1
00053540 T fclose
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:
Group       : System Environment/Libraries   Source RPM:
Size        : 26821530    License: LGPL
Packager    : Red Hat Software
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 20:09:59 UTC
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 23:58:59 UTC
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.