Hi Andreas,
Andreas Tille, on 2020-10-12 17:56:38 +0200:
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> 103 | __asm__ ("cpuid\n\t" \
> | ^~~~~~~
> third_party/cpuid.h:162:3: note: in expansion of macro ‘__cpuid’
> 162 | __cpuid (__ext, __eax, __ebx, __ecx, __edx);
> | ^~~~~~~
> third_party/cpuid.h:103:3: error: impossible constraint in ‘asm’
> 103 | __asm__ ("cpuid\n\t" \
> | ^~~~~~~
> third_party/cpuid.h:185:3: note: in expansion of macro ‘__cpuid’
> 185 | __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
> | ^~~~~~~
> In file included from ebwt_build.cpp:8:
> ...
>
> Any idea how to deal with this?I believe that cpuid.h is an architecture specific header, but the upstream source code ships with a custom third_party/cpuid.h which probably mainly targets amd64, hence issues on non amd64. I ran an arm64 build a few minutes ago, after having excluded third_party/. This way, the source code gently failed back to the system provided cpuid.h which should be always be appropriate. My build went through on arm64, as well as the test suite. > [1] > https://salsa.debian.org/med-team/bowtie/-/blob/master/debian/patches/popcnt_capability.patch As a side note, I believe that the $(filter ...) statement added in the patch to be able to list architectures reverted the logic, so replaced the ifeq (...) statement to an ifneq (...). Most changes are available on my machine. I would have suggested to push them, but my build targeting mips64el failed and it seems that its because `uname -m` returns mips64 on that architecture. I'm not 100% sure of the name for the other architectures, maybe listing CPUs handling popcnt might be simpler ? Anyway in hope any of these ideas helps... Kind Regards, -- Étienne Mollier <etienne.moll...@mailoo.org> Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
