-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compilation issue on ARM64 architecture #88
Comments
[Transferred to htscodecs.] What compiler is this please? Would be good to check and look at the warnings. The I may be able to get an Ubuntu 22.04 AWS ARM instance running though to see some of this for myself. |
We did wonder in PR #63 whether some of that was going to need to be conditionalised further… The compiler is conda-forge's build of GCC. I have checked, and the headers in the related sysroot_linux-aarch64 conda package do indeed define As you have |
@jkbonfield thanks for the quick reply! The compiler should be from anaconda's package
Thanks for the help! |
@jmarshall I've tried to add
But I can't see any change in the logged output. Should I apply the change somewhere else instead? |
That's not the right place to do it, as that Makefile line is just a list of dependencies. It'll probably complain that it doesn't know how to make You could try adding
Note that you might have to substitute |
There you go:
|
Which version of the
but the previous one (
Unfortunately I've not been able to track down why this change happened in this Conda package, but it looks like version 2.28 might fix your HTSlib compilation. |
I've tweaked our CI and managed to get @RenzoTale88's build going. conda is now pulling the more recent sysroot 2.28 of its own accord. The issue seemed to be a bad |
That sysroot package contains glibc headers. The aarch64 hardware capability bits were added in glibc 2.24 in 2016. Glibc 2.17 is from late 2012, only a year after aarch64 was introduced. I suppose the code could pander to ancient libc but 🤷 maybe it's better to find out that you're not going to get SIMD… -#elif defined(__linux__) && defined(__aarch64__)
+#elif defined(__linux__) && defined(__aarch64__) && defined(HWCAP_ASIMD) // & similarly in other #elifs Glad to hear your conda configuration has now been sorted out. |
Conda 🙄 , I don't know why we do it to ourselves. |
🤣 Conda has its problems, but on a (user) population basis it's better than the alternative 🧵. |
Given there are some gcc13 warnings we should be fixing too, maybe I'll add a Glad to hear though that this is just a broken compiler quirk which has already been resolved upstream. Edit: Also agreed - Conda has big problems and it could have been be so much better. Too many starting points to trip up the naive first time user (which conda? which resolver? what order of evaluation in package lists? etc). However for all the conda problems we field here and my occasional gripes at it, I expect there would be even more "how do I build..." queries if it didn't exist. |
A broken conda config removed HWCAP_ASIMD definition. It's fixed now, but we check with ifdefs as suggested by John Marshall in comments on the issue. Hence code is buildable, just minus NEON support on specific OS and hardware combinations. Fixes samtools#88
This works around samtools/htscodecs#88, whereby the default older sysroot_linux-aarch64 2.17 does not define HWCAP_* values on ARM and so Neon codec implementations are unused as have_neon() is always 0.
This works around samtools/htscodecs#88, whereby the default older sysroot_linux-aarch64 2.17 does not define HWCAP_* values on ARM and so Neon codec implementations are unused as have_neon() is always 0.
This works around samtools/htscodecs#88, whereby conda-forge's older sysroot_linux-aarch64 2.17 does not define HWCAP_* values on ARM and so Neon codec implementations are unused as have_neon() is always 0. Avoid this by including the kernel header to get the desired values.
* Add additional-platforms entry * Work around old sysroot_linux-aarch64 version This works around samtools/htscodecs#88, whereby conda-forge's older sysroot_linux-aarch64 2.17 does not define HWCAP_* values on ARM and so Neon codec implementations are unused as have_neon() is always 0. Avoid this by including the kernel header to get the desired values.
Hello,
I'm trying to compile htslib v1.17 for multiple architectures, including on an aarch64 machine with ubuntu 22.04, as part of an anaconda build. The compilation works fine on x86_64 and Mac ARM64, but fails on linux AARCH64 with the following error while compiling
htscodecs
:I've tried also with v1.18, but with the same issue.
Any suggestion on how to fix this?
Thanks in advance
Andrea
The text was updated successfully, but these errors were encountered: