Re: __xstat et al. as compat symbols

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Adhemerval Zanella:

>> I think the impact of that is a bit narrower because it requires special
>> compiler flags.  But I suspect I will ask for reverting that in a year
>> as well. 8-/
>
> It is sad that we can't get rid of clunky and not well thought interface,
> which kind of issues are you seeing that is making you thinking about
> reverting the libm finite symbols?

Based on the failures I've seen so far, Ocaml would have to start
distributing binaries for glibc 2.32 and earlier (probably built on
something like glibc 2.17) and glibc 2.33 and later (built on glibc
2.33).  Other native code compilers are likely affected in the same way.

>>> The issue is only for static linking, by stopping using
>>> libc_nonshared.a we need to provide the versioned stat symbols anyway.
>>> And we still need to handle new ABIs where adding the old xstat
>>> symbols does not make sense (such as riscv32 or any new 32-bit
>>> architecture).
>> 
>> You could use a SHLIB_COMPAT conditional without compat_symbol, the two
>> are separate.
>
> The problem is with:
>
>   #if SHLIB_COMPAT(libc, GLIBC_2_4, GLIBC_2_33)
>   int
>   __fxstatat (int vers, int fd, const char *file, struct stat *st, int flag)
>   {
>   }
>   #endif
>
> It won't be built for static and without using SHLIB_COMPAT in this 
> case will build the interfaces for ABIs that doe not require it.

We could rename TEST_COMPAT and use that, I think it already has the
right semantics.  Or you could use “ifdef have-GLIBC_2.32” at the
makefile level.

>>> If we just defer the compat move, it would add the needless symbols on
>>> newer ABIs that we will need to keep supporting indefinitely (even
>>> though they won't be used anywhere unless user explicily links against
>>> a protected symbol) and we would eventually need to handle the y2038
>>> support on old ABIs (with the _TIME_SIZE selection) by either adding
>>> proper 64-bit time support for by removing the xstat for good.
>> 
>> See above, we can (and should) remove it on newer ABIs only.
>
> So now is we are moving in providing what is supposed to be compat
> symbols in the static library case as well. Do we really want to start
> supporting such scenario?

Downstream, we do not need these symbols for fully static linking, so
SHLIB_COMPAT would actually be okay for our needs, I think.

I guess if upstream rejects this, we can provide a stub library that can
be used to link against the __xstat et al. symbols as a workaround.  But
if we need it, Debian (with its lack of per-release mass rebuilds) will
likely need it too, and some other distributions probably as well.  So
at that point, I think we need to ask ourselves as upstream developers
whether we are really serving the needs of our users.

Maybe this is coming across a bit strongly, I just want to put it out
there.  If Fedora rawhide breaks after we make a change that is
technically correct because it affects officially unsupported
configurations only, it makes sense to pause and think if what we are
doing is really correct.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill