Problems with symbols from libc_nonshared (fwd)

[Zack Weinberg <zack@rabi.columbia.edu>]

This is a bugreport forwarded from Debian.  I think we need to use a version
map to force libc_nonshared.a symbols local when building shared libraries,
sort of like what HJ did for libgcc.a in his egcs/Linux patches.

zw


------- Forwarded Message

Date:    Fri, 26 Mar 1999 12:47:56 +0100
From:    Richard Braakman <dark@xs4all.nl>
To:      35049@bugs.debian.org
cc:      maor@debian.org
Subject: Bug#35049: More information

(I'm Cc:ing the bash maintainer on this one.  Guy, please see the logs
for bug#35049 for the context.)

I found the difference.  bash 2.01.1 was compiled without
optimization, and bash 2.02.1 was compiled with -O2.  (This means we
shipped slink with an unoptimized bash, hmph.)

Without optimization, the stat functions defined in <sys/stat.h> are
not inlined.  They are referenced as external symbols, and the glibc
people expect that they will be found in libc_nonshared.a.

When a shared library is compiled without optimization, it links these
unshared definitions in, and for some reason exports them again.  They
are now shared, and unoptimized programs that use this library will
find the shared definitions rather than the static ones.

I think this is a bug in glibc, since it silently pollutes the binary
interface of such libraries.  It is aggravated by glibc2.1, because
the "stat" symbols can now be "stat64" symbols, silently changing the
binary interface.

Note that libreadline is always built non-optimized, for both bash
versions. When I looked for the reason, I found it in the debian/rules
file!  libreadline in bash 2.02.1-1.3 is specifically re-built without
optimization:

# Why override CFLAGS below?  Weird segfaults with the previous bash
# which was accidentally non-optimized and an optimized readline.
        rm lib/readline/{*.o,*.so}
        $(MAKE) -C lib/readline SOVERSION=$(soversion) CFLAGS=-g libreadline.so
 libhistory.so

Argh!  The problem was already known, but not properly fixed.

(libreadline in bash 2.01.1-4.1 was built non-optimized because
the whole package was; it did not have these lines in the rules file).

In the glibc sources, I see in the Makeconfig file that it was known
that these routines can end up in other shared libraries:

# Must build the routines as PIC, though, because they can end up in (users')
# shared objects.  We don't want to use CFLAGS-os because users may, for
# example, make that processor-specific.

(This is a comment for the code that sets compilation flags for
libc_nonshared.a)

What I still don't know is _why_ these definitions are unshared.
It seems to me that it can only cause problems.  What does it solve?

I see two ways to deal with the current situation.

Strategy 1

The symbol table pollution in libreadline is glibc's fault.  glibc
should deal with it by defining the necessary symbols dynamically.

This will fix bash, and prevent reoccurrence of this problem in
other libraries.  But if it is done only by Debian, it may cause binary
incompatibility with other platforms.

Strategy 2

For better or worse, libreadline's binary interface now includes
"stat" and "stat64" symbols (and lstat, etc...), and it must maintain
these symbols until its soname changes.  This might be done by copying
the defintions from <sys/stat.h>.

This may cause binary compatibility with other platforms, but no worse
so than we have already, and it will only affect binaries linked with
libreadline.  However, it does not fix other libraries that may have
this problem, and it remains to trap the unwary.


--  
To UNSUBSCRIBE, email to debian-glibc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


------- End of Forwarded Message