This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 87684 - Relinking Oracle 9iR2 fails on RedHat 9
Relinking Oracle 9iR2 fails on RedHat 9
Status: CLOSED UPSTREAM
Product: Red Hat Linux
Classification: Retired
Component: libc (Show other bugs)
9
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-01 03:24 EST by Shawn Walker
Modified: 2007-04-18 12:52 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-07 08:00:48 EDT
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 Shawn Walker 2003-04-01 03:24:38 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Relinking Oracle 9iR2 fails on RedHat 9

[root@swalker bin]# ./relink client_sharedlib
/opt/oracle/bin/genclntsh
/opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x74): In function `kgupdpg':
: undefined reference to `__ctype_b'
/opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0xb9): In function `kgupdpg':
: undefined reference to `__ctype_b'
/opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x10a): In function `kgupdpg':
: undefined reference to `__ctype_b'
/opt/oracle/lib/libclient9.a(kgupd0.o)(.text+0x14a): In function `kgupdpg':
: undefined reference to `__ctype_b'
/opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x3772): In function `kudmchs':
: undefined reference to `__ctype_toupper'
/opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x3791): In function `kudmchs':
: undefined reference to `__ctype_b'
/opt/oracle/lib/libclient9.a(kudmi.o)(.text+0x37c2): In function `kudmchs':
: undefined reference to `__ctype_toupper'

....

And so on. Relinking under RedHat 8 worked fine. Are there different libraries
or a different way I need to relink it now?

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


How reproducible:
Always

Steps to Reproduce:
1. edit gencltnsh script to link against -lgcc properly
2. run link script
3. see linker fail with undefined symbols to "__ctype_b", etc.
    

Additional info:
Comment 1 Shawn Walker 2003-04-01 16:23:37 EST
The good news is that copying an installation of the client from an existing
RedHat 8.x system allows me to run the client and use the OCI libraries in my
local development (thankfully). This issue just prevents me from doing an
installation directly on my box using the Oracle installer. (Since I can't
relink the libraries).
Comment 2 Jakub Jelinek 2003-04-07 08:00:48 EDT
This is a bug in Oracle (the way they are relinking stuff is inherently error-prone,
they have been bitten by this already once (with IPC) and have not changed their
install process yet).
Please report this to Oracle instead.
Comment 3 Shawn Walker 2003-04-07 10:59:11 EDT
Thanks for the information, more of an FYI than anything. I figured as much, has
RedHat suggested a better linking solution to them?
Comment 4 Werner Puschitz 2003-06-05 00:28:26 EDT
But it's interesting that the RH 9 CDs I bought work fine with Oracle9iR2. These
CDS come with glibc-2.3.2-5. And the images that are available for download come
with glibc-2.3.2-11.9. The glibc-2.3.2-5 exports __ctype_b as compatibility
symbol, but glibc-2.3.2-11.9 doesn't. 

$ rpm -ql glibc-2.3.2-5 | grep libc.so
/lib/i686/libc.so.6
/lib/libc.so.6
/lib/tls/libc.so.6
$ nm -a /lib/i686/libc.so.6 | grep __ctype_b
001315f8 D __ctype_b
00022340 T __ctype_b_loc
$ nm -a /lib/libc.so.6 | grep __ctype_b
00133c58 D __ctype_b
000223a0 T __ctype_b_loc
$


$ rpm -ql glibc-2.3.2-11.9 | grep libc.so
/lib/i686/libc.so.6
/lib/libc.so.6
/lib/tls/libc.so.6
$ nm -a /lib/i686/libc.so.6 | grep __ctype_b
00131718 D __ctype_b@GLIBC_2.0
000223a0 T __ctype_b_loc
$ nm -a /lib/libc.so.6 | grep __ctype_b
00133d58 D __ctype_b@GLIBC_2.0
000223f0 T __ctype_b_loc
$

So why has Red Hat suddenly changed this in Red Hat 9 between glibc-2.3.2-5 and
glibc-2.3.2-11.9?

Werner
Comment 5 Werner Puschitz 2003-06-20 14:29:13 EDT
What's the status on this? Why has Red Hat suddenly changed this in Red Hat 9
between glibc-2.3.2-5 and glibc-2.3.2-11.9? And will Red Hat exports __ctype_b
as compatibility symbol again?

Or should I open a new ticket?

Werner
Comment 6 Michael Young 2003-06-20 17:19:22 EDT
I am sure I have seen the answer to this query elsewhere in bugzilla. The
reasoning (if I remember correctly) is that the __ctype_b isn't safe in the TLS
environment, so they removed it to discourage people from using it. Hence don't
expect it to reappear, though it is apparently quite easy to modify the glibc
source to turn the exporting back on.
Comment 7 Michael Young 2003-06-20 17:33:04 EDT
See http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00093.html
for information on how to modify the glibc source so the symbols work again.
Also the problem is with uselocale, not TLS.
Comment 8 Shawn Walker 2003-06-20 22:03:45 EDT
The point is that they're internal symbols and no sane application should be
using them anyway.

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