Re: RFC: Add GNU_PROPERTY_1_GLIBC_2_NEEDED

[Michael Matz <matz@suse.de>]

Hello,

On Thu, 28 Oct 2021, H.J. Lu via Binutils wrote:

> > >> This proposal may conflict in spirit with the glibc proposal to support
> > >> preloadable symbol version (so you can add _dl_find_eh_frame@GLIBC_2.35
> > >> to a glibc 2.28 installation, for example).  So far, symbol versions
> > >
> > > Why will adding a glibc version dependency change the preload
> > > behavior?
> >
> > Previously, we thought we could relax the version coverage check to
> > enable adding completely new symbol versions by preloading an
> > implementation.  With BIND_NOW, this is completely safe because missing
> > symbols are still detected.  But this turns unreliable once glibc
> > versions are tied to ELF implementation features.  Preloading an
> > implementation of _dl_find_eh_frame@GLIBC_2.35 (for example) will not
> > add dynamic linker features first implemented in glibc 2.35.
> 
> I am not sure if I am following your concerns.   We have an ELF feature,
> like DT_RELR, which is tied to a glibc version.  The binary with DT_RELR
> will crash with the older glibcs.  And you DON'T want such a binary with
> a dependency on the required glibc version.  Can you tell me why?

You never want to test for versions to imply absence or presence of 
features.  You want to test for the feature, or alternatively for an 
indication of said feature.  Such indication could be the existence of a 
fake symbol (which can have a symbol version, no less), some flag 
mechanism (where to-be-defined flags would mean features), or suchlike.  I 
find the idea of symbols the most intuitive one.  DT_RELR binaries could 
require (from their .dynsym), say '_dl_have_relr', and glibc supporting it 
would provide that feature.

Version checks always run into trouble vs. backports, and simply aren't 
the right tool.


Ciao,
Michael.