(apologies if this is the wrong forum, there didn’t seem to be a specific one for distro packaging queries)
I maintain raspbian, an armv6 rebuild of Debian. I have been looking to update the julia package in raspbian bullseye to bring it back into sync with Debian.
However after building the package I found it set off our armv7 contamination checker. Specifically /usr/lib/arm-linux-gnueabihf/julia/libopenblas64_.so showed as containing armv7 code.
Sometimes there are false-positives, i.e. code that is safely tucked behind runtime CPU checks. However I do not know enough about julia to check this with a reasonable degree of effort.
Can anyone from upstream advise?
OpenBLAS is one of those special cases that embeds within itself multiple different versions of a function, choosing at runtime the one that best matches the current host CPU. I would not be surprised if by default it compiles for multiple 32-bit arm architectures at once, especially since armv6 and armv7 are so similar. We have similar checks inside of BinaryBuilder, however if a binary contains a
cpuid instruction, we generally assume it’s “doing the right thing” inside of itself and don’t raise a fuss.
As a side note, we unfortunately don’t have armv6 binaries for the majority of our packages (due to lack of support within BinaryBuilder), which means that the JLL packages that work great on most other platforms won’t work for you, so you will most likely have a very hard time dealing with any kind of binary dependencies on armv6.
Thanks for your comments, I decided to go ahead and assume it’s probably a false positive and upload the package to raspbian…
On your side note I don’t know enough about the julia ecosystem to understand how significant it is. I don’t actually use julia, I just build it.