Symbols missing from global map?
Keith Owens
kaos@ocs.com.au
Wed Dec 16 04:47:00 GMT 1998
>Submitter-Id: net
>Originator: Keith Owens
>Organization:
*** O . C. Software -- Consulting Services for Storage Management, ***
*** Disaster Recovery, Security, TCP/IP, Intranets and Internet ***
*** for mainframes (IBM, Fujitsu, Hitachi) and Unix. ***
>Confidential: no
>Synopsis: Symbols that should be global are local
>Severity: serious
>Priority: low
>Category: libc
>Class: sw-bug
>Release: libc-2.0.106
>Environment:
<machine, os, target, libraries (multiple lines)>
Host type: i586-pc-linux-gnu
System: Linux ocs4 2.1.131 #1 SMP Thu Dec 3 22:08:53 EST 1998 i586 unknown
Architecture: i586
Addons: crypt linuxthreads
Build CC: egcs
Compiler version: egcs-2.90.29 980515 (egcs-1.0.3 release)
Kernel headers: 2.1.131
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
After compiling and installing glibc 2.0.106, programs
complained about unresolved symbols, e.g. __dup2, __pipe,
__waitpid and others. nm on glibc-2.0.106-build/io/dup2.o
showed __dup2 as type T (extern), also type T in all the static
libraries, libpic.a etc. But it was type t (static) in
libc.so.6.
The problem seems to be correlated with the PSEUDO entries,
several of the __sym entry points that I expect to be global
are static in libc.so.
>How-To-Repeat:
Standard compile.
>Fix:
Adding __dup, __pipe, __waitpid etc. to build/libc.map makes
them visible again. I am guessing here, this may be the wrong
fix.
More information about the Libc-alpha
mailing list