Re: [Help] Need help for architecture specific code (Was: Bug#756780: bowtie: FTBFS almost everywhere)
+++ Andreas Tille [2014-08-04 09:48 +0200]:
> Hi,
>
> on arm*, powerpc, sparc and s390x architectures the build problem is:
>
> third_party/cpuid.h: In constructor 'Ebwt<TStr>::Ebwt(int, int32_t, int32_t, int32_t, int32_t, int32_t, const string&, bool, bool, uint32_t, uint32_t, uint32_t, int, std::vector<FileBuf*>&, std::vector<RefRecord>&, std::vector<unsigned int>&, uint32_t, const RefReadInParams&, uint32_t, int32_t, int32_t, bool, bool, bool) [with TStr = seqan::String<seqan::SimpleType<unsigned char, seqan::Dna_>, seqan::Alloc<> >; int32_t = int; std::string = std::basic_string<char>; uint32_t = unsigned int]':
> third_party/cpuid.h:162:46: error: impossible constraint in 'asm'
> __cpuid (__ext, __eax, __ebx, __ecx, __edx);
> ^
> third_party/cpuid.h:185:52: error: impossible constraint in 'asm'
> __cpuid (__level, *__eax, *__ebx, *__ecx, *__edx);
Those are x86 register names.
> on mips* the problem is:
>
> /tmp/cciY8R8w.s:161449: Error: unrecognized opcode `push{l} $14'
> /tmp/cciY8R8w.s:161450: Error: unrecognized opcode `popf{l|d}'
> /tmp/cciY8R8w.s:161451: Error: unrecognized opcode `pushf{l|d}'
> /tmp/cciY8R8w.s:161452: Error: unrecognized opcode `pop{l} $14'
> /tmp/cciY8R8w.s:161453: Error: unrecognized opcode `popf{l|d}'
> /tmp/cciY8R8w.s:161585: Error: unrecognized opcode `cpuid'
> /tmp/cciY8R8w.s:161606: Error: unrecognized opcode `cpuid'
And those are x86 instructions
So from this info it looks a lot like it is building assembly code
that can only work on x86.
You need to either stop this package from building on other
architectures, or arrange to use C instead of asm on other
architectures (it may well have some fallback C for this already).
This package has probably never been built for anything other than
amd64 before.
This package tries to do some optimised stuff and this code may well
be about finding out the hardware capabilities in order to optimse
correctly. You almost certainly don't actually need assembler for that
and even if it did, intrinsics are usually a much better plan than
real assembler these days.
> I admit I do not have the slightest idea how to deal with issues
> like this. Any (also partial help) is welcome.
Hopefully the above will provide some clues. Ask upstream if it's even
been built for other arches? Look for C fallbacks. Certainly disable
building x86 ASM on non-x86 arches.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: