Date: Tue, 29 Oct 2019 11:20:35 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: lfs64 api removal 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
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.