Re: gold not finding symbols in ld-linux.so.2

[Kris Van Hees <kris dot van dot hees at oracle dot com>]

On Wed, Jul 02, 2008 at 10:38:19AM -0700, Ian Lance Taylor wrote:
> Kris Van Hees <kris.van.hees@oracle.com> writes:
> 
> > On Wed, Jul 02, 2008 at 09:00:30AM -0700, Ian Lance Taylor wrote:
> >> Then we are all still missing something.  gold does not complain about
> >> undefined symbol references in shared libraries.  Why is it
> >> complaining here?
> >
> > Well, the old linker behaviour seems to be that allow-shlib-undefined is false,
> > unless linking a shared library, in which case it is true (and anything on
> > the command line or in linker scripts that uses GROUP also has it false for
> > the time being because groupos are meant to be self-contained).
> >
> > Gold on the other hand doesn't distinguish between a shared library linking
> > and a non-shared library linking, in simply uses allow-shlib-undefined false
> > by default.  At least in my case, that seems to be causing the unexpected
> > complaint during the linking about unresolved symbols.  So, specifying
> > --allow-shlib-undefined on the command line with gold solves the problem,
> > but it definitely is a difference with the old linker behaviour.
> 
> Whoops, you're quite right.  I forgot about the twisty passages here.

I'm looking into how to fix this with as small and elegant as a patch as
possible, but it's a rather interesting piece of logic :)

> In Symbol_table::warn_about_undefined_dynobj_symbol I see that we
> explicitly don't warn about libraries found in the system library
> directory, that being the directory in which we find libc.so.  I
> wonder why that didn't help here?

There is one immediate problem I can see with this logic: some projects
e.g. provide a stub-version of the C library which is (for lookup reasons)
obviously also named libc.so.* and this causes the heuristic that determines
the system library path to fail rather badly.  It find the stub, and sets
the system library path as something completely different from /lib etc.

	Kris