+++ 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/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804115842.gc22...@stoneboat.aleph1.co.uk