Re: [PATCH v2] elf: Implement filtering of symbols historically defined in libpthread

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, May 6, 2021 at 2:17 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Wed, May 5, 2021 at 1:48 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >>
> >> On Wed, May 5, 2021 at 1:17 PM Florian Weimer via Libc-alpha
> >> <libc-alpha@sourceware.org> wrote:
> >> >
> >> > * Andreas Schwab:
> >> >
> >> > > When bison is rebuilt with a linker that contains binutils commit
> >> > > b293661219c, it no longer crashes, and this patch isn't needed.
> >> >
> >> > Hmm.  I worry we need to preserve compatibility with old binaries.  Not
> >> > everyone can do distribution bootstrap or has the source code to carry
> >> > it out.
> >>
> >> We never guarantee that applications linked against the old unversion
> >> glibc work with the versioned glibc today.  Otherwise, we don't need
> >> glibc version at all.
> >
> > We can hide symbols for undefined, weak, unversioned references
> > from the old versioned binaries.
>
> If it's okay to deliberately break backwards compatibility with some old
> binaries, wouldn't we not use a patch at all?  That's drop this patch
> and just use what's currently in the tree?
>
> I'm not sure which group of old binaries is more important (deliberate
> use of unversioned weak symbols in recent times vs binaries linked
> against glibc 2.0 using the accidentally).  If it's okay to break
> things, I'm leaning towards “no patch” (despite having spent quite some
> time on it).

We should maintain backward compatibility with versioned binaries.   For
unversioned binaries, we can check DT_NEEDED with libpthread.so.6.

> I may have to come back to this topic in a year or so, based on end user
> feedback.  Given that the symbol filter does not have ABI impact, it's a
> backportable change, so I'm not too concerned to get this right
> immediately.
>
> Thanks,
> Florian
>


-- 
H.J.