Bug 6930

Summary:	Both GLIBC_2.0 and GLIBC_2.1 suffixes for some APIs
Product:	[Retired] Red Hat Linux	Reporter:	gk4
Component:	glibc	Assignee:	Cristian Gafton <gafton>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	gk4
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
URL:	http://x26.deja.com/getdoc.xp?AN=546521605&CONTEXT=942338142.2065563766&hitnum=0
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-01-04 23:58:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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"
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
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:
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 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