Re: glibc 2.33.9000 version checks and in memory file name change

[Mark Wielaard <mark@klomp.org>]

Hi,

On Wed, Jul 14, 2021 at 01:55:27PM -0300, Adhemerval Zanella wrote:
> On 09/07/2021 13:37, Mark Wielaard wrote:
> > That tells to suppress an Helgrind Race condition if the backtrace
> > originated for an in memory object file matching */lib*/libc-2.*so*.
> > This suppression fails now since /usr/lib64/libc.so.6 doesn't match
> > that pattern.
> > 
> > I wonder if there are other programs which might depend on the in
> > memory file name of glibc and might be impacted by this change.
> 
> I am not sure, but relying on such naming scheme is fragile in principle:
> although the installation did use the embedded the version in the 
> installed filename nothing preventes the distribution to rename it to
> something complete different (since the DT_NEEDED will still point to
> libc.so.6).

Yes, it would be nicer to have used the so name, but people are more
familiar with the actual file name. It also used to be more
architecture independent. Because of the symlinks ld.so was named the
same on all arches. I certainly understand this was just by accident
and we shouldn't have relied on it, but...

> > Now we can update our default suppressions and will do so.
> > 
> > Unfortunately our current mechanism for doing that relies on a
> > configure check for the glibc version. Specifically we check whether
> > features.h defines __GLIBC__ __GLIBC_MINOR__ and construct the glibc
> > version from that. But current development versions of glibc (like
> > Fedora rawhides glibc-2.33.9000) still report __GLIBC_MINOR__ as 33.
> 
> What kind of regular expression does valgrind suppression mechanism
> support? Does it mimic the shell expansion used on glob(), for instance,
> or is it something more restrict?

It only knows about * (zero or more) and ? (zero or one) chars.

> > Is there a way to detect this is really 2.33.9000 aka almost 2.34? Or
> > could you up the __GLIBC_MINOR__ already now that people are starting
> > to ship test versions like 2.33.9000?
> 
> We now moved all libpthread/librt/libdl symbols to libc.so, so if you
> must detect 2.34 glibc you may try use pthread_create without linking
> to -lpthread.

Thanks, that is a nice check. I used that for now.
https://bugs.kde.org/show_bug.cgi?id=439590

> Usually we do follow the release procedure to just bump
> de version to 2.34 once the release is actually done.

Understood, and it is too late to change that for this release.  But
maybe for the next features.h could be changed at the freeze point
instead of at release? Then people will test against the actual
release number.

Thanks,

Mark