Bug 90515 - unresolved symbol __ctype_b when linking Performer apps
unresolved symbol __ctype_b when linking Performer apps
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-05-09 00:01 EDT by Tom Flynn
Modified: 2016-11-24 09:57 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-05 14:16:03 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)

  None (edit)
Description Tom Flynn 2003-05-09 00:01:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126
Netscape6/6.2.1

Description of problem:
When trying to compile a Performer application, one gets the following
linker error:

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libpf.so: undefined reference
to `__ctype_b'

One was able to compile, link and run Performer applications on previous
releases of Redhat (rh8 and earlier).  This is pretty critical since this means
that no performer applications can be developed on Redhat 9.

I tried upgrading to the glibc listed in the errata:

http://rhn.redhat.com/errata/RHBA-2003-136.html

but it did not solve the problem.
 
(Performer is a scene-graph library used for 3d visualization, see
www.sgi.com/software/performer)


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

How reproducible:
Always

Steps to Reproduce:
1. install redhat 9

2. goto www.sgi.com/software/shader/downloads.html and
download and install SGIshader (a prereq for Performer).
install both rpms.

3. goto www.sgi.com/software/performer/downloads.html and download
and install the gcc3 version of Performer.  you need at least the performer_dev,
performer_eoe, performer_demos, performer_demo_license rpms.

4. as root: cd /usr/share/Performer/src/sample/C/perfly/
   and type: make



Actual Results:  got the following linker error:

/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libpf.so: undefined reference
to `__ctype_b'
collect2: ld returned 1 exit status


Expected Results:  should have produced a perfly binary.

Additional info:
Comment 1 Tom Flynn 2003-05-19 19:05:05 EDT
This appears to be related to a discussion on the debian-glibc mailing list...
Here's the comment from Roland McGrath <roland@redhat.com>:

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?
Comment 2 Rob Swindell 2003-07-02 17:45:26 EDT
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
Comment 3 Ben Chang 2003-08-09 16:27:21 EDT
glibc-2.3.2-5 from the RH9 CD install works (perfly will build w/o errors).  
Comment 4 Ulrich Drepper 2003-11-05 14:16:03 EST
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.
Comment 5 Rob Swindell 2003-11-05 15:21:26 EST
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
Comment 6 Ulrich Drepper 2003-11-05 15:27:14 EST
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.

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