Bug 90515
| Summary: | unresolved symbol __ctype_b when linking Performer apps | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Tom Flynn <flynnt> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | drepper, fweimer, rob |
| 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: | 2003-11-05 19:16:03 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
Tom Flynn
2003-05-09 04:01:56 UTC
This appears to be related to a discussion on the debian-glibc mailing list... Here's the comment from Roland McGrath <roland>: http://lists.debian.org/debian-glibc/2002/debian-glibc-200210/msg00093.html The flexlm static library Performer links against seems to fall into this category. I patched and recompiled glibc to have the references to compat_symbol and ctype_b taken out. I'll send you the patch i used if you want. (had to comment out lines in ctype/ctype-info.c and locale/lc-ctype.c). After installing the new glibc and rebooting, Performer programs would compile. However, when the programs were run, they would segfault. The stack trace led back to the flexlm lc_checkout() function using malloc() and malloc() was causing the segfault. I did most of this investigation on a friend's machine over the weekend. I'm currently recompiling glibc here at work to reproduce it here. Once I've done that I can give you the stack trace I got. The following are the steps I used to modify and recompile glibc. Can you verify that they should work? 1) grabbed the src rpm from here: http://rhn.redhat.com/errata/RHBA-2003-136.html 2) rpm -Uvh glibc-2.3.2-27.9.src.rpm 3) I untarred the glibc-2.3.2-200304020432.tar.bz2 from the SOURCES directory to a directory of my own. And untarred it to a directory called glibc-new. From there, I commented out the lines I needed to in ctype/ctype-info.c and locale/lc-ctype.c. Then I created a diff with diff -Naur glibc-2.3.2-200304020432 glibc-new > glibc-ctype_b.patch I copied that patch into the SOURCES directory. I modified the glibc-9.spec in the SPECS directory to add my patch in. 4) rpmbuild -ba --target=i686-redhat-linux glibc-9.spec >& log 5) wait a couple hours. 6) installed the rpms in the RPMS/i686/ directory and rebooted. is there anything else I should've done? I too have this problem with "undefined reference to '__ctype_b'" when linking with library files created with older versions of RedHat Linux. I've also submitted a GNATS bug report for glibc, http://bugs.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- trail&database=glibc&pr=5068 So hopefully somebody will fix this bug finally. -Rob glibc-2.3.2-5 from the RH9 CD install works (perfly will build w/o errors). There is nothing in public releases which will make this work. Object files are not guaranteed to be compatible with the runtime after a system upgrade. Only executables and DSOs are guaranteed. Period. So, get somebody to fix the application which has problems to not rely on object file compatibility or at least provide alternative object files for different OS releases. The only alternative is to compile your own glibc with some changes to export the needed symbols. Don't expect help from me, I do not want such bastard glibc versions to exist. This is no bug and I'm going to close it appropriately. It should be noted that the exact same problem happens with DSOs (which "are guaranteed to be compatible"), unless the DSO (lib*.so file) is linked with version symbols, which requires using gcc to link instead of ld. While this allows foreward compatibility (older .so's will then work on upgraded systems) - it does *not* allow for backward compatibility. That is, .so's built on upgraded systems are still not compatible with older systems. -Rob It never has been nor will it ever be allowed to link anything (program or executable) with ld directly. The gcc driver must always be used. Any DSO which is not linked this way is broken anyway. It uses the interfaces from the headers but doesn't used versioned symbols. This cannot work. |