binutils-2.11.90.0.6: ld fails to link necessary .a file members to resolve symbols in automatically loaded .so files

[Adam J. Richter]

        I am cc'ing this to address@hidden because it is a bug
that becomes a lot more visible when using glibc-2.2.3, and 
at first looks like a glibc bug.  Hopefully this message will
help people on bug-glibc recognize other reports of this problem
and avoid the need to duplicate this investigation.

        On the Linux system on which this problem occurs, the "ncurses"
shared library is set up to automatically load the "gpm" dynamic
library (used for mouse input).  So, a program that was linked
with a command like:

                cc -o myeditor myeditor.o -lcurses

        will actually load the curses and gpm shared libraries when
it runs.

        Well, it appears that the glibc-2.2.3 release exposes a bug
in ld, where ld does not bring in all of the files that it needs for
resolving the symbol in one of these automatically loaded libraries
that was not specified on the dependency.  In particular, gpm references
the "atexit" function, which is now in /usr/lib/libc_unshared.a
(archive member: atexit.oS) which is referenced in the ld script
/usr/lib/libc.so.  Here is the behavior of ld (actually, I'm faking
this from my experiments with making bash-2.05):

        cc -o myeditor myeditor.o -lcurses
        /usr/lib/libgpm.so.1: undefined reference to `atexit'
        collect2: ld returned 1 exit status

        cc -o myeditor myeditor.o -lcurses /usr/lib/libc_unshared.a
        /usr/lib/libgpm.so.1: undefined reference to `atexit'
        collect2: ld returned 1 exit status

        cc -o myeditor myeditor.o -lcurses -lgpm
        # works

        ar x /usr/lib/libc_unshared.a atexit.oS
        cc -o myeditor myeditor.o -lcurses atexit.oS
        # works

        There is some question as to what the right behavior of
ld should be with respect to these hidden shared library dependencies.
For compatability with static linking, ld could refuse to consider
automatically loaded libraries at all (thereby requiring "-lcurses
-lgpm" instead of "-lcurses", as is necessary with static libraries
when curses is build to use gpm).  It could be argued that the automtic
loading feature is intended for compatability when shared libraries
are upgraded, not for linking new programs.  For linking new programs,
perhaps configure scripts should have the responsibility for finding
libraries' dependencies (even if just by extracting the autoloading
information from the .so's and turning it into expliciy command line
arguments).

        However, the closest thing to the current ld behavior would
be to fix ld so that undefined symbols in automtically loaded libraries
that are not given on the command line will still cause the necessary
files from subsequent .a's on the command line (like /usr/lib/libc_unshared.a)
to be compiled in.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
address@hidden     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."