Re-enable _LARGEFILE64_SOURCE when _GNU_SOURCE is defined

[sbc100]

When we updated to the latest version of musl it broke some codebases that were using LFS functions (e.g. stat64) and assuming those functions would be defined when _GNU_SOURCE is defined.

See bminor/musl@25e6fee

This change effectively reverts the above one by defining _LARGEFILE64_SOURCE whenever _GNU_SOURCE is defined.

This is what glibc does:

https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/include/features.h#L206

[kleisauke]

According to https://musl.libc.org/releases.html this was done on purpose and codebases that depend on these legacy LFS64 glibc-ABI-compat symbols should be fixed instead:

On the API level, the legacy "LFS64" ("large file support") interfaces, which were provided by macros remapping them to their standard names (#define stat64 stat and similar) have been deprecated and are no longer provided under the _GNU_SOURCE feature profile, only under explicit _LARGEFILE64_SOURCE. The latter will also be removed in a future version. Builds broken by this change can be fixed short-term by adding -D_LARGEFILE64_SOURCE to CFLAGS, but should be fixed to use the standard interfaces.

However, I'm aware that Rust builds are currently broken due to this, I submitted a PR for this at rust-lang/libc#3308 last month. For the same reason, Alpine has not shipped this in the v3.18.x cycle, see commits:
https://git.alpinelinux.org/aports/commit/?id=5fb59dcff01ea8dacd86d08216636794ad08ddd1
https://git.alpinelinux.org/aports/commit/?id=cab9b787b39387f0b3d30d218b0739c3e21aefb8

[sbc100]

According to https://musl.libc.org/releases.html this was done on purpose and codebases that depend on these legacy LFS64 glibc-ABI-compat symbols should be fixed instead:

On the API level, the legacy "LFS64" ("large file support") interfaces, which were provided by macros remapping them to their standard names (#define stat64 stat and similar) have been deprecated and are no longer provided under the _GNU_SOURCE feature profile, only under explicit _LARGEFILE64_SOURCE. The latter will also be removed in a future version. Builds broken by this change can be fixed short-term by adding -D_LARGEFILE64_SOURCE to CFLAGS, but should be fixed to use the standard interfaces.

However, I'm aware that Rust builds are currently broken due to this, I submitted a PR for this at rust-lang/libc#3308 last month. For the same reason, Alpine has not shipped this in the v3.18.x cycle, see commits: https://git.alpinelinux.org/aports/commit/?id=5fb59dcff01ea8dacd86d08216636794ad08ddd1 https://git.alpinelinux.org/aports/commit/?id=cab9b787b39387f0b3d30d218b0739c3e21aefb8

I think going with that glibc does and being a little more friendly to legacy software is good course of action for emscripten in this case. Its fine for upstream musl to be more strict than us

[sbc100]

OK to land this?

[kripken]

lgtm to land quickly if this is blocking something.

[dschuff]

According to https://musl.libc.org/releases.html this was done on purpose and codebases that depend on these legacy LFS64 glibc-ABI-compat symbols should be fixed instead:

On the API level, the legacy "LFS64" ("large file support") interfaces, which were provided by macros remapping them to their standard names (#define stat64 stat and similar) have been deprecated and are no longer provided under the _GNU_SOURCE feature profile, only under explicit _LARGEFILE64_SOURCE. The latter will also be removed in a future version. Builds broken by this change can be fixed short-term by adding -D_LARGEFILE64_SOURCE to CFLAGS, but should be fixed to use the standard interfaces.

However, I'm aware that Rust builds are currently broken due to this, I submitted a PR for this at rust-lang/libc#3308 last month. For the same reason, Alpine has not shipped this in the v3.18.x cycle, see commits: https://git.alpinelinux.org/aports/commit/?id=5fb59dcff01ea8dacd86d08216636794ad08ddd1 https://git.alpinelinux.org/aports/commit/?id=cab9b787b39387f0b3d30d218b0739c3e21aefb8

I think going with that glibc does and being a little more friendly to legacy software is good course of action for emscripten in this case. Its fine for upstream musl to be more strict than us

Doing this in the short term seems fine to unblock users, but I'm not convinced this will work in the longer term. As mentioned, LARGEFILE_64_SOURCE is going away upstream in the next release, and I'm not sure we want to maintain downstream patches for this (especially not integrated into various headers the way these are, as that would be an invasive change to maintain). We should probably try to figure out whether we can keep this compatibility in a more easily-maintainable way, or maybe we can help our users fix their code.

[sbc100]

I think punting for now is fine. "The latter will also be removed in a future version" isn't necessarily the next release.. and musl releases a few and far between. I think we can pick the best option for dealing with that event once it happens.