[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <04ef2139-f4d6-162c-ff7c-9f849939391f@adelielinux.org>
Date: Tue, 29 Oct 2019 10:43:54 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: musl@...ts.openwall.com
Subject: Re: lfs64 api removal
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.
>
> 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.
>
> 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
>
> weak_alias(foo,foo64);
>
> with something like:
>
> __asm__(".symver foo,foo64@");
>
> 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.
>
> The other simple way is also a hack: have ldso recheck failed lookups
> just in libc, with any 64 removed, before committing to failure.
>
> 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.)
>
> 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.
>
> 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
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
