Bug 12773 - /usr/lib/libc.so is missing an entry for libc.a
/usr/lib/libc.so is missing an entry for libc.a
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-21 03:00 EDT by stevecassidy
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-06-21 19:53:33 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 stevecassidy 2000-06-21 03:00:28 EDT
I was  having problems linking against a third party library
-- I got undefined symbols for _fxstat and others.  I found
the answer in the glibc FAQ 

http://www.gnu.org/software/libc/glibc-FAQ.html

question 17 talks about what should be in /usr/lib/libc.so and says
that various symbols (fstat included) are undefined in libc.so.6 
and so programs need to link agains libc.a instead. 

The default /usr/lib/libc.so with Redhat 6.2 is:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )  

I added an entry for libc.a:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a /usr/lib/libc.a )  

and my code compiles with no missing symbols.  

I haven't tried to generate a minimal program to reproduce this, but
I just thought I'd share this with you all.
Comment 1 Bill Nottingham 2000-06-21 16:48:15 EDT
You shouldn't be doing that; the unshared symbols should all be present
in libc_nonshared.a. What sort of a library are you linking against?
Comment 2 stevecassidy 2000-06-21 19:53:33 EDT
This is a library from Entropic (now owned by Microsoft)
which reads speech data files.  The linking error
showed a missing _fxstat amongst a few others, nm on
/usr/lib/libc_nonshared.a doesn't show _fxstat, just 
__fxstat while /usr/local/libc.a has both.  

Here's some output from an attempted compile with
the original libc.so:
gcc  -fno-builtin  -O -DSCCS -I/opt/esps531.linux/include -DLINUX -DNO_LIC 
sgram.o  /opt/esps531.linux/lib/libexv.a /opt/esps531.linux/lib/libhdre.a
/opt/esps531.linux/lib/libespsg.a  -lm -o sgram
/opt/esps531.linux/lib/libhdre.a(headers.o): In function `fstat':
/usr/include/sys/stat.h:155: undefined reference to `_fxstat'
/opt/esps531.linux/lib/libhdre.a(headers.o): In function `error_msg':
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `__setjmp'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `__setjmp'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `__setjmp'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `_xstat'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `_xstat'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `_fxstat'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `__setjmp'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `__setjmp'
/home/projects/devel_source/general/src/lib_header/pc_wav.c:798: undefined
reference to `_xstat'
/opt/esps531.linux/lib/libespsg.a(pfparser.o): In function `stat':
/usr/include/sys/stat.h:135: undefined reference to `_xstat'
/opt/esps531.linux/lib/libespsg.a(putsym.o): In function `stat':
/usr/include/sys/stat.h:135: undefined reference to `_xstat'
collect2: ld returned 1 exit status
make: *** [sgram] Error 1               

This compiles ok with the modified version of libc.so.


Comment 3 Jakub Jelinek 2000-08-24 06:37:37 EDT
The library references internal glibc symbols which are now hidden by
symbol versioning. That is a big no no, implementation of the unexported
symbols may change any time.

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