Koka
Fix system detection when cross-compiling with Yocto
In Yocto the target can be for example aarch64-poky-linux, which is most definitely gnu, but doesn't contain the gnu infix in the target.
Instead, detect Linux using CARGO_CFG_TARGET_OS and assume that it's gnu or musl.
@ogoffart it is, but I haven't fixed our musl problem (#99) yet, and that blocks all further work.
Okay, I'm back!
The assumption that on Linux it's always GNU or musl appears to be wrong:
$ rustc --print target-list | grep linux | egrep -v -- '-gnu|-musl'
aarch64-linux-android
aarch64-unknown-linux-ohos
arm-linux-androideabi
armv5te-unknown-linux-uclibceabi
armv7-linux-androideabi
armv7-unknown-linux-ohos
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
i686-linux-android
mips-unknown-linux-uclibc
mipsel-unknown-linux-uclibc
riscv64-linux-android
thumbv7neon-linux-androideabi
x86_64-linux-android
x86_64-unknown-linux-ohos
Even if all of those have libintl (which I didn't check), there's no guarantee that in a few years Rust won't add a new triple for a platform that doesn't have libintl. So I think this approach is a dead end.
We could introduce a feature (force-gettext-system or assume-libc-contains-libintl or something) which always links with libc without checking if it has libintl. It'll be backed by an environment variable too. Will that be a workable solution for you?
Okay, I'm back!
Yay :)
The assumption that on Linux it's always GNU or musl appears to be wrong:
$ rustc --print target-list | grep linux | egrep -v -- '-gnu|-musl' aarch64-linux-android aarch64-unknown-linux-ohos arm-linux-androideabi armv5te-unknown-linux-uclibceabi armv7-linux-androideabi armv7-unknown-linux-ohos armv7-unknown-linux-uclibceabi armv7-unknown-linux-uclibceabihf i686-linux-android mips-unknown-linux-uclibc mipsel-unknown-linux-uclibc riscv64-linux-android thumbv7neon-linux-androideabi x86_64-linux-android x86_64-unknown-linux-ohosEven if all of those have libintl (which I didn't check), there's no guarantee that in a few years Rust won't add a new triple for a platform that doesn't have libintl. So I think this approach is a dead end.
Fair point.
We could introduce a feature (
force-gettext-systemorassume-libc-contains-libintlor something) which always links with libc without checking if it has libintl. It'll be backed by an environment variable too. Will that be a workable solution for you?
In a way that’s how I expect the “gettext-system” feature to work. I think that’s also how it works with other crates: if I enable the “system-foo” feature it’s my responsibility to make sure it’s in the system.
In this crate the feature enables a kind of auto-detection (that’s failing in my case).