Hi Étienne,
On Mon, Oct 12, 2020 at 10:22:39PM +0200, Étienne Mollier wrote:
> > 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.
Hmmmm, may be I should remove third_party/cpuid.h in general?
Given its copyright informazion is
Copyright (C) 2007, 2008, 2009 Free Software Foundation, Inc.
that seems to be a pretty old copy of this file.
> > [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...
Would you mind sending a `git diff` to make sure I fully
understood what you mean?
Kind regards
Andreas.
--
http://fam-tille.de
