Bug 87684
Summary: | Relinking Oracle 9iR2 fails on RedHat 9 | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Shawn Walker <drevil> |
Component: | libc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED UPSTREAM | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 9 | CC: | mitr, webmaster |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | athlon | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-04-07 12:00:48 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
Shawn Walker
2003-04-01 08:24:38 UTC
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). 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. Thanks for the information, more of an FYI than anything. I figured as much, has RedHat suggested a better linking solution to them? 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 000223a0 T __ctype_b_loc $ nm -a /lib/libc.so.6 | grep __ctype_b 00133d58 D __ctype_b 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 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 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. 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. The point is that they're internal symbols and no sane application should be using them anyway. |