Symbols missing from global map?

[Keith Owens <kaos@ocs.com.au>]

>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.