[Top][All Lists]

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

Re: Undefined use of weak symbols in gnulib

From: Florian Weimer
Subject: Re: Undefined use of weak symbols in gnulib
Date: Mon, 12 Jul 2021 17:03:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

* Michael Hudson-Doyle:

> Did this thread ever reach a conclusion? I'm testing a snapshot of
> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on
> startup on ppc64el.

For us it got resolved with a binutils fix:

commit b293661219c36e72acb80502a86b51160bb88cfd
Author: Alan Modra <amodra@gmail.com>
Date:   Mon May 3 10:03:06 2021 +0930

    PPC: ensure_undef_dynamic on weak undef only in plt
    It's slightly weird to have a call to a weak function not protected by
    a test of that function being non-NULL, but the non-NULL test might be
    covered by a test of another function.  For example:
      if (func1)
          func1 ();
          func2 ();
    where func2 is known to exist if func1 exists.
            * elf32-ppc.c (allocate_dynrelocs): Call ensure_undef_dynamic for
            weak undefined symols that only appear on PLT relocs.
            * elf64-ppc.c (allocate_dynrelocs): Likewise.

We rebuilt bison and a couple of other packages that looked like it
would be affected by this before putting glibc 2.34 snapshots into the
buildroot, and that worked quite well for us.  (Thanks to Andreas Schwab
for identifying the issue so early.)

We don't know yet whether there are user binaries out there which will
be incompatible with glibc 2.34.  I have posted a glibc patch which
alters symbol resolution to increase compatibility with old binaries (so
it's technically feasible to get this working again), but in the review
discussion, I was asked to break *more* older binaries, including every
i386 binary from the late 1990s/early 2000s, so I dropped that patch and
did not pursue this approach further.  But I guess we can get back to it
if feedback from end users indicates that the current approach doesn't
work for them.


reply via email to

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