bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Adam J. Richter
Subject: Patch(?): binutils-2.11.90.0.6/ld/ldlang.c fix to resolve undefined DT_NEEDED symbols
Date: Sun, 29 Apr 2001 20:25:57 -0700
User-agent: Mutt/1.2i

        This is a follow-up to my message earlier today reporting the
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 am cc'ing this to address@hidden, so they can have status
information to pass on, as I think people who trip over this will
initially think it's a glibc bug.

        The cause of this problem is apparently because the DT_NEEDED
files are brought in by an architecture-specific handler
(ldemul_after_open) that is called after all of the regular input
files have been selected.

        The following patch makes ld continue looping through
open_input_bfds and ldemul_after_open, until the list of undefined
symbols is unchanged.  I have verifier that when this patched version
of ld attempts to link bash (which has the ncurses --> gpm --> atexit
dependency problem), the link works, and the resulting bash runs.
I have also verified that it seems to be OK when given a bad link
that has an undefined symbol.

        One quirk that this patch introduces is that it will
look at *every* file on the command line to resolve *all remaining*
undefined symbols, if a DT_NEEDED .so file brought in any new undefined
symbols, not just the ones that occurred after the .so that broght
in the DT_NEEDED file.

        Frankly, I would rather that ld try every file given
on the command line if the link would otherwise fail with an
undefined symbol, rather than having the link file.  That could
easily be done by moving the "undefs = ..." assignment in this
patch up one line.  If that were the case, then you could get rid
of the --{start,end}-group support.  However, I assume that this
behavior has some positive purpose or is mandated by some standard.

        By the way, I am not tremendously confident that this is
the perfect patch.  I am not very familiar with ld internals.

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

Attachment: binutils.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]