Bug 87749 – GLIBC_2.0 not defined in file libc.so.6

Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 87749 - GLIBC_2.0 not defined in file libc.so.6

Summary:	GLIBC_2.0 not defined in file libc.so.6

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Raw Hide
Classification:	Retired
Component:	glibc (Show other bugs)
Sub Component:
Version:	1.0
Hardware:	athlon Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Jakub Jelinek
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2003-04-01 19:50 EST by Airbete
Modified:	2016-11-24 10:10 EST (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2003-04-03 04:31:30 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)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Airbete 2003-04-01 19:50:04 EST

Description of problem: 
I have a binary (which I cannot recompile since it's a commercial product) that was working 
fine with glibc-2.3.1-6 and glibc-2.3.1-51. But since I upgraded to glibc-2.3.2-11.9 it doesn't 
work anymore. I get this error: 
 
"symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference" 
 
It looks like there is an incompatibility problem. But am I correct to say that 2.3.1 executables 
should normally be able to run with glibc 2.3.2? 
 
Version-Release number of selected component (if applicable): 
glibc-2.3.2-11.9 
 
Thanks.

Comment 1 Jakub Jelinek 2003-04-03 04:31:30 EST

There is a compatibility problem for broken binaries only.
No binary or library compiled against glibc 2.1+ should ever reference
errno, h_errno or _res symbols (errno etc. are macros which expand to
*__errno_location(), etc.).
You can use LD_ASSUME_KERNEL=2.4.1 (or 2.2.5) in the broken apps environ
to work around this, or if it is in the binary and not its libraries the
dynamic linker should do the workaround automatically.

Comment 2 Airbete 2003-04-03 17:36:42 EST

Thanks a lot. It DID solve my problem. :-)

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