Re: PATCH: Fix gold problem with weak undefined symbols

["Cary Coutant" <ccoutant at google dot com>]

>  Even if we argue that that is a bug, and that we should change glibc
>  to resolve these relocations when possible, and that we should change
>  the GNU linker to emit these dynamic relocations, we have to deal with
>  today's reality: if we emit those dynamic relocs today, an executable
>  built from the above code will not run on x86-64, because the dynamic
>  linker will give an error about an unexpected reloc type.
>
>  Suggestions?

As far as I'm concerned, weak symbols are a legacy from the days of
static linking. Weak definitions were originally introduced to solve
the ANSI C namespace pollution problem, and weak references to
optionally-defined symbols fell out of that as a useful thing to have.
With shared libraries, we don't need weak definitions to avoid
namespace pollution, and we have the dlsym() API for testing for the
presence of optional symbol definitions.

I think the current behavior of weak undefs is ingrained -- we've
already found two apps here at Google that depend on the current
behavior of GNU ld, and I believe in the old rule of thumb that the
only correct answers to "how many?" are zero, one, and many.

While the argument for consistency between archive libraries and
shared libraries is reasonable, it can also be carried too far. On
HP-UX, we originally tried to mimic the object file granularity that
you have with archives, and ended up with a real mess.

Rather than trying to change this for the sake of consistency, we
should be encouraging apps to use more modern methods for dealing with
optional symbols.

-cary