From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14883 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "A. Wilcox" Newsgroups: gmane.linux.lib.musl.general Subject: Re: lfs64 api removal Date: Tue, 29 Oct 2019 10:43:54 -0500 Organization: =?UTF-8?Q?Ad=c3=a9lie_Linux?= Message-ID: <04ef2139-f4d6-162c-ff7c-9f849939391f@adelielinux.org> References: <20191029152035.GD16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BMPDSbaEMcN7Y47PVafwsoSH1bmT9XVSg" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="84895"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux ppc64; rv:68.0) Gecko/20100101 Thunderbird/68.0 To: musl@lists.openwall.com Original-X-From: musl-return-14899-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 29 16:44:23 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iPTfS-000LyL-P6 for gllmg-musl@m.gmane.org; Tue, 29 Oct 2019 16:44:22 +0100 Original-Received: (qmail 1411 invoked by uid 550); 29 Oct 2019 15:44:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 1393 invoked from network); 29 Oct 2019 15:44:19 -0000 Autocrypt: addr=awilfox@adelielinux.org; prefer-encrypt=mutual; keydata= mQINBE+DjPIBEADTQ1H/e/avDUhgt8+T3TJpjGYoY9Y47EMfHqWMm9LjR9aiZSG6GWRbpjWS 4V0DqzIhNQw7HLkPws9CVqQkmpIeltQyGDV2qcR5AXxJ4lCRWHxwRzWE0cCzhLUR9BBWOO0U NINQY+2IqmzRAqXZ9zL+mGTles/qeheXmaWLKf/T0kqJFihoM+ItQvUWOkWUdVv0prhzXr9Q QUdt0NTIW8n4sPwtuSvQgqwSzCJQArh1myugVSGiIIN38pCU8g41Vh35mHHhbHjbn0o1mhrX B/gbsndGo7QQBKz4CPaSel+Fl92dCvVWTp1XYyjqeZx2xlx1zfDrXOTuzY1WmNHi7BgHYuem tG7Zyp7u9MR6FvLKgQhmvCQZXaa+9oNtwKckxoP/I5R8ede9YRb6pLyG5JC0pTTk7kpUZCX2 tm8pLKy899zomm8BBm71aEJHE44ABEl/PbM7tA7XhSPiWsdBmVCxH4bqpUgGMx0ztqhNsUul SDDhiAWgtYFHATynhmeKBDKthkO7lj4CzwI54dn1uiwDtvUFVyVsPMjJcCxFnONbOPcvm1R9 sDg5sn57dv0f+EtaU3ppZdotutjM9X7OEC93d1flO3k1LO20qn2ZcI24f3tEOLAjn5xZ1GdV 3BYBwrtuaaiO8tMdp0uAtILzkkrcr0vOi2/SngxtXFw+44X+WQARAQABtDNBLiBXaWxjb3gg KEFkw6lsaWUgTGludXgpIDxhd2lsZm94QGFkZWxpZWxpbnV4Lm9yZz6JAjoEEwEIACQCGwMF CwkIBwIGFQgJ In-Reply-To: <20191029152035.GD16318@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14883 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BMPDSbaEMcN7Y47PVafwsoSH1bmT9XVSg Content-Type: multipart/mixed; boundary="t8Wq3TwdVsMpZhnTrQo870Hx1SuRyVkyi" --t8Wq3TwdVsMpZhnTrQo870Hx1SuRyVkyi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 29/10/2019 10:20, Rich Felker wrote: > One roadmap item I had down for this release cycle, whose practicality > at this point I need to assess, is removal of the lfs64 stuff at the > API level. The intent is that all the macros defining "64"-suffixed > alternate names for interfaces and types involving off_t would be > removed, but the symbols would still be present for linking only > (possibly dynamic linking only). These macros tend to break C++ stuff > since GCC's default _GNU_SOURCE in C++ mode exposes them all, and > unlike glibc's definitions, musl's are at the preprocessor level where > they can't be namespaced or shadowed. And they're just ugly, useless, > and possibly misleading. >=20 > Ideally we could just remove all of this from the public headers, but > at least at one point in the past, lots of software used broken > configure tests which were link-only to infer their existence, then > without the corresponding declarations or macros in the public > headers, produced implicit function definitions using them with > horribly wrong behavior as a result. As I recall it, this was the > motivation for adding them to begin with. >=20 > If that's still an issue, removing the API while keeping the ABI > requires some mechanism to make them unavailable at ld-time but > available at ldso time. The easiest way seems to be replacing >=20 > weak_alias(foo,foo64); >=20 > with something like: >=20 > __asm__(".symver foo,foo64@"); >=20 > which produces a non-default empty-versioned symbol. This seems to > also require -Wl,--default-symver to work. ("Seems", because nothing > connected to symbol versioning hell is actually documented.) It also > depends on ldso ignoring non-default symbol versions and only > resolving to the default version, which probably isn't done right now > because we don't use versions for libc/ldso itself at all. So while > the source-level change is simple, there's some real ugliness here > that might interact badly with other things in the future. >=20 > The other simple way is also a hack: have ldso recheck failed lookups > just in libc, with any 64 removed, before committing to failure. >=20 > Further alternatives are making a fake virtual dso to hook > glibc-linked (DT_NEEDED:libc.so.6) apps/libs up to and providing the > lfs64 symbols from there, or dropping them entirely from musl, moving > them to gcompat, and instead adding a feature for auto-loading gcompat > for glibc apps/libs. (These approaches involve more detail I haven't > gone into here.) >=20 > Ideally, I'd be really happy to find out that just removing the cruft > from the headers suffices, so that we can consider getting rid of the > linkable symbols as s completely separate matter later if desired > rather than having to do them together. >=20 > Rich Sounds like this may be worth a try-build, like what we are going to do for the time64 changes on PPC32 and ARMv7. If you want to write a patch that completely removes the LFS64 API, I can toss it to one of our ultra-fast builders (ppc64 probably) and see where it goes. (Likely after the time64 try-build, if that's acceptable.= ) If it is possible to remove them entirely from musl, then wearing my gcompat maintainer hat, I'd be happy to work with the musl community to add whatever support code would be necessary from our end to make it work for providing the LFS ABI to musl. That was actually the original design goal... Best, --arw --=20 A. Wilcox (awilfox) Project Lead, Ad=C3=A9lie Linux https://www.adelielinux.org --t8Wq3TwdVsMpZhnTrQo870Hx1SuRyVkyi-- --BMPDSbaEMcN7Y47PVafwsoSH1bmT9XVSg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjNyWOYPU1SaTSMHHyynLUZIrnRQFAl24XjoACgkQyynLUZIr nRSb1w/+INRYT0uUBHeNYbpWxk5FFkIn++CFNANtG55Tz7dLxqjIpt57HTMMVztn xguarJ12dgo9e420a9/a9Mgb7sqkOVGp+UZ+nJjHlMxOghhtkfBEEJGgiRc03Xn8 gWiD+9CRPZADkzxhuylsBbyAayEKN2fooFryTTRSN81tRmAgWvqcPsBfFPRQYTtp ynbl0B5ni2d8PqQbjtdViJbvjFbWfd/0YhGNJU+/tuWrVO6UWGQCI55jYtu1pLXf RIEUzUbd57xE+//oLkkT1UbDhty0mKdLflp581kBC4ji/GF9UHqvJvUjWYui/PkU VLjHj6vqV7u2h4KVcbpyNx+/q8tibVS2slCHHwyvGZj71Wk9W0SpwClJQ58gy3z1 3Y6Ctn8dISq9mNxjGi5WGAgBD1DING2RWoHjEu9ZxFcIRp4bSzjyTBAbUPKP2LIH TWTAlrv8ztp/E6QpJScqretGzZyz3tVkPmcwuOipyYbbzPXj3SPB9/jxCQpOwazM sLHpL1c87rpXUDHB48/NwABST4i/SeY0+bEH+2X1fGuqt7a8ypHjTfv/czhVnTWO rvkvg8KrzZZDxmr49m33sBZwyR546prJl2T4salAYphRIoBFrL8N0cP269QtDcNJ aXs0nTTMrw2rcwD9285D0YYTEKONOeUsLFsctd0WJaD29tPx1Ag= =hwyQ -----END PGP SIGNATURE----- --BMPDSbaEMcN7Y47PVafwsoSH1bmT9XVSg--