[Debian-med-packaging] Bug#972004: Assembly code not working for mips64el and ppc64el (Was: Bug#972004: bowtie ftbfs on several release architectures)

Andreas Tille andreas at fam-tille.de
Tue Oct 13 08:06:52 BST 2020


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



More information about the Debian-med-packaging mailing list