Hi,
thanks for the hints which I forwarded upstream. While I've got no
explicit answer about this a new version was released which now even
fails to build on amd64 but with a different error. My guess is that
this is caused since upstream includes a code copy of an older version
of seqan-dev and we patched the code to cope with the latest version
in Debian. While beeing no C++ coder I guess another patch for
compatibility with the new version would be needed.
I commited the packaging to SVN[1] and the error message looks like
make[2]: Entering directory '/tmp/buildd/bowtie-1.1.0'
g++ -O3 -DCOMPILER_OPTIONS=\-O3 -Wl,--hash-style=both -DPOPCNT_CAPABILITY
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wl,-z,relro\ -Wl,--hash-style=both
-DPOPCNT_CAPABILITY -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong
-Wformat -Werror=format-security -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wl,-z,relro \
-fno-strict-aliasing -DBOWTIE_VERSION=\`cat VERSION`\
-DBUILD_HOST=\`hostname`\ -DBUILD_TIME=\`date`\
-DCOMPILER_VERSION=\`g++ -v 21 | tail -1`\ -
D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DPREFETCH_LOCALITY=2
-DBOWTIE_MM -DBOWTIE_SHARED_MEM -DNDEBUG -Wall \
-I /usr/include/seqan -I third_party -I third_party \
-o bowtie-build-s ebwt_build.cpp \
ccnt_lut.cpp ref_read.cpp alphabet.cpp shmem.cpp edit.cpp ebwt.cpp
tinythread.cpp bowtie_build_main.cpp \
-lpthread
In file included from blockwise_sa.h:13:0,
from ebwt.h:27,
from ebwt_build.cpp:11:
diff_sample.h: In member function 'void DifferenceCoverSampleT::build()':
diff_sample.h:859:3: error: '_Context_LSS' was not declared in this scope
_Context_LSSTIndexOff c;
^
diff_sample.h:859:25: error: expected primary-expression before '' token
_Context_LSSTIndexOff c;
^
diff_sample.h:859:27: error: 'c' was not declared in this scope
_Context_LSSTIndexOff c;
^
Makefile:205: recipe for target 'bowtie-build-s' failed
make[2]: *** [bowtie-build-s] Error 1
Any help would be really welcome
Andreas.
[1] svn://anonscm.debian.org/debian-med/trunk/packages/bowtie/trunk/
On Mon, Aug 04, 2014 at 12:58:42PM +0100, Wookey wrote:
+++ 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 'EbwtTStr::Ebwt(int, int32_t,
int32_t, int32_t, int32_t, int32_t, const string, bool, bool, uint32_t,
uint32_t, uint32_t, int, std::vectorFileBuf*, std::vectorRefRecord,
std::vectorunsigned int, uint32_t, const RefReadInParams, uint32_t,
int32_t, int32_t, bool, bool, bool) [with TStr =
seqan::Stringseqan::SimpleTypeunsigned char, seqan::Dna_, seqan::Alloc
; int32_t = int; std::string = std::basic_stringchar; 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