Date: Mon, 26 Sep 2022 18:03:32 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: Revisiting LFS64 removal 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.