Bug 150680

Summary: glibc does not export functions
Product: Red Hat Enterprise Linux 3 Reporter: Jens Westermann <jens.westermann>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-09 15:36:01 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jens Westermann 2005-03-09 11:18:19 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.6)
Gecko/20050226 Firefox/1.0.1

Description of problem:
We need to install the version 9.1D of the database Progress.
Therefore it's necessary to run a "probuild", this fails with
undefined references _ctype_b. 

undefined reference to '__ctype_b'
undefined reference to '__ctype_tolower'
undefined reference to '__ctype_toupper'
Fatal error when running probuild ldpro script on Linux
probuild on Linux fails with undefined references __ctype_b
__ctype_tolower __ctype_toupper

The problem is related to glibc version on RH 3.0. The newer versions
of glibc do not export __ctype_b() and 2 other functions.



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


How reproducible:
Always

Steps to Reproduce:
1.Installation of the database
2.Running the "probuild" command
3.Running the command "ldpro" / "ldprort"
    

Actual Results:  undefined reference to '__ctype_b'

Expected Results:  New database startup file should be made.

Additional info:
Comment 1 Jakub Jelinek 2005-03-09 15:36:01 EST
Those symbols are prohibited for all newly linked programs/libraries, because
they aren't thread safe.
glibc ensures binary compatibility for shared libraries and binaries only,
while apparently Progress is trying to link objects that were compiled on
different glibc against the RHEL3 glibc.  That never worked reliably and never
will.  Either you need to recompile them against RHEL3 glibc, then you can also
link them against that glibc, or you need to link them against the glibc that
was used to compile them.

RHEL3 includes compat-glibc package, which could help you, as that's glibc
from AS 2.1.
So compiling and linking with gcc -B /usr/lib/i386-redhat-linux7/lib/
-static-libgcc -L /usr/lib/i386-redhat-linux7/lib/
-I/usr/lib/i386-redhat-linux7/include/ could work.