Re: Patch(?): binutils-2.11.90.0.6/ld/ldlang.c fix to resolve undefined DT_NEEDED symbols

Re: Patch(?): binutils-2.11.90.0.6/ld/ldlang.c fix to resolve undefined DT_NEEDED symbols

[H . J . Lu]

On Sun, Apr 29, 2001 at 08:25:57PM -0700, Adam J. Richter wrote:
> 
> 	This is a follow-up to my message earlier today reporting the

Please CC all binutils bug reports to binutils@sourceware.cygnus.com.
If it can be duplicated in my Linux bintuils, also CC to hjl@lucon.org.

> ld bug where if a .so file pulled in another .so file not given on
> the command line (via DT_NEEDED the ELF feature), the undefined symbols
> in that additional .so file would fail to cause a file that defined those
> symbols to be included in the link.  For example, libncurses.so can
> require libgpm.so, and libgpm.so refers to the atexit() function, which
> requires a static chunk of C library code to be included, even when
> the shared C library is linked in (atexit trigger this is new under
> glibc-2.2.3).

I don't think ld should check those DSOes brought in by DT_NEEDED. FYI,
glibc 2.2.3 requires a gcc with the patch

http://gcc.gnu.org/ml/gcc-patches/2001-03/msg01164.html

installed. gcc 2.96-81 in RedHat 7.1 is ok. gcc 2.95.3 is NOT ok. The
gcc in CVS has that patch.


H.J.

Re: Patch(?): binutils-2.11.90.0.6/ld/ldlang.c fix to resolve undefined DT_NEEDED symbols

[H . J . Lu]

On Mon, Apr 30, 2001 at 04:17:31PM -0700, Adam J. Richter wrote:
> >Please CC all binutils bug reports to binutils@sourceware.cygnus.com.
> >If it can be duplicated in my Linux bintuils, also CC to hjl@lucon.org.
> 
> 	I think I may not have sent you the original bug report,
> and I know I did not send it to the binutils@sourceware.cygnus.com
> address libc-alpha@sourceware.cygnus.com.  So, I have attached it
> below.  (After this message, I plan to trim back the cc's as
> appropriate.)

Which gcc did you use to compile glibc 2.2.3?


H.J.

Re: Patch(?): binutils-2.11.90.0.6/ld/ldlang.c fix to resolve undefined DT_NEEDED symbols

[Adam J. Richter]

>Please CC all binutils bug reports to binutils@sourceware.cygnus.com.
>If it can be duplicated in my Linux bintuils, also CC to hjl@lucon.org.

	I think I may not have sent you the original bug report,
and I know I did not send it to the binutils@sourceware.cygnus.com
address libc-alpha@sourceware.cygnus.com.  So, I have attached it
below.  (After this message, I plan to trim back the cc's as
appropriate.)

	libgpm really does call atexit() in gpm.c.  It is not just
a side-effect of crtstuff.c.

	Given the example failures I describe in my original bug
report, what do you think the correct course of action should be for
program maintainers?  Can we get at least a more descriptive error
message?  It is not clear that the program needs to *add* "-lgpm"
given an error message like this:

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


	I think this error will happen with most curses-based programs.

	Perhaps we could have a macro in autoconf that will extract
all of the dependent libraries from a .so so they can be put on the
command line.  That would still require a lot of programs to be changed,
but it would provide a hook for handling other types of library
interdependency in the future.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  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."
---------------------------------------------------------------------------
From adam@yggdrasil.com Sun Apr 29 17:59:31 2001
Received: from baldur.yggdrasil.com (baldur.yggdrasil.com [209.249.10.12])
	by ns1.yggdrasil.com (8.9.3/8.9.3) with ESMTP id RAA06808;
	Sun, 29 Apr 2001 17:59:27 -0700
From: "Adam J. Richter" <adam@yggdrasil.com>
Received: (from adam@localhost)
	by baldur.yggdrasil.com (8.9.3/8.9.3) id RAA19754;
	Sun, 29 Apr 2001 17:59:27 -0700
Date: Sun, 29 Apr 2001 17:59:27 -0700
Message-Id: <200104300059.RAA19754@baldur.yggdrasil.com>
To: bug-binutils@gnu.org
Subject: binutils-2.11.90.0.6: ld fails to link necessary .a file members to resolve symbols in automatically loaded .so files
Cc: bug-glibc@gnu.org

	I am cc'ing this to bug-glibc@gnu.org 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
adam@yggdrasil.com     \ /                  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."