Re: [musl] Revisiting LFS64 removal

[Markus Wichmann <nullplan@gmx.net>]

On Sun, Sep 25, 2022 at 09:03:40PM -0400, Rich Felker wrote:
> Seeing a recent wrong-fix commit in binutils
> (https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=fe39ffdc202f04397f31557f17170b40bc42b77a)
> reminded me of the longstanding "we need to remove LFS64" issue.
>

Whenever I see stuff like that, it makes me break out in hives. The
stupidest part is that the commit is adding configure tests, so they
could just test for the things they want. But no, they test for
something unrelated and then assume that that has the implications they
want.

> I believe the simplest short-term way is probably going to be just
> having the dynamic linker symbol lookup error path make one final
> check before bailing out with an error:
>
> - If the symbol to lookup ends in "64"..
> - ..and it's in a hard-coded list of LFS64-compat symbols..
> - ..and looking up the name with the "64" removed in libc succeeds..
>
> Then use the version without the "64" suffix and go on with relocation
> processing.
>

Took me a while to figure out what you were trying to do here: You want
to hide the LFS64 symbols at link-time. At compile-time, the macros
prevent actual use of those symbols, at link-time, access will fail, but
the symbols will still be there at dynamic load-time, so existing
binaries don't break.

Of course, that means that you will have to keep the kludge around for
the foreseeable future, as even if those symbols are added to
libgcompat, existing binaries would break if it were removed (since
existing binaries do not depend on libgcompat), which violates the musl
ABI stability goals. Oh well, it's not going to be the last bit of
legacy cruft in the library.

Ciao,
Markus