X11Libre
Update ones.c
__has_builtin is a compiler feature, so the C library that is used is entirely irrelevant. What matters is the compiler you are using.
Your fix actually makes the code compile with GCC < 10 and with non-Clang, non-GCC compilers that do not implement this extension, independently of the C library that is being used.
Your fix actually makes the code compile with GCC < 10 and with non-Clang, non-GCC compilers that do not implement this extension, independently of the C library that is being used.
Do we have any actual need to support those compilers ?
@lm8 how did you confirm that this patch is needed ? Could it be that you just happen to have an old compiler for the musl target ? Which distro and toolchain are you using ?
__has_builtinis a compiler feature, so the C library that is used is entirely irrelevant.
Confirmed. XLibre compiles fine on musl libc without this patch.
I started with a current stable Debian system. I used Rich Felker's build for a musl cross compiler (git clone https://github.com/richfelker/musl-cross-make.git). Used most of the config.mak settings as they were and just added target and output. I built the compiler. I went through LFS/BLFS documents for all the package dependencies needed to build X11Libre. I spent several days including my vacation time building all the prerequisites from source. You can take or leave the patch I sent. My results from this are that X11Libre fails to build as is on that system.
@lm8 Thank you very much for your effort! Would you like share to what steps you have taken to set up LFS/BLFS etc. to build XLibre?
That toolchain build system defaults to GCC_VER = 9.4.0 which is indeed < 10. Considering that GCC 10 is 5 years old, this is getting really old. There is support for GCC up to 14.2.0, I do not know why they do not default to a newer version.
That said, I think adding your simple fix should not be a problem.
@lm8 Thank you very much for your effort! Would you like share to what steps you have taken to set up LFS/BLFS etc. to build XLibre?
If someone would be interested, I'd be okay with sharing. I use my own package management/build scripts. I'm still trying to figure logistics on the best way to share the scripts. The input that creates the scripts would be pretty useless without the package/build tools. The output is a bash script customized for a specific system with paths and core utilities available on that system. So someone would have to modify that if they wanted to use the bash script on another system with different paths or tools. Each script also needs the source tarball for the package. So, if I added the scripts to a git repository, wondering if I needed to add the tarballs they work with for completeness. Not sure if it makes sense storing tarballs via git. Might just be easier if someone's interested, I can email them information on what I did. What do you think is the best method of sharing information of that nature?
That toolchain build system defaults to
GCC_VER = 9.4.0which is indeed < 10. Considering that GCC 10 is 5 years old, this is getting really old. There is support for GCC up to 14.2.0, I do not know why they do not default to a newer version.That said, I think adding your simple fix should not be a problem.
If I rebuild this again to test out my scripts, I'm definitely updating the gcc toolchain. Just used the defaults with the musl cross build last time. I do know a few systems that use older GNU toolchains, so the fix could be useful on those systems.