Bug#756780: [Help] Need help for architecture specific code (Was: Bug#756780: bowtie: FTBFS almost everywhere)
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
Bug#756780: [Help] Need help for architecture specific code (Was: Bug#756780: bowtie: FTBFS almost everywhere)
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);
^
make[2]: *** [bowtie-build] Error 1
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'
make[2]: *** [bowtie-build] Error 1
and on *-i386 the problem seems to be
typedef typename ValueTStr::Type TAlphabet;
^
ebwt.h: Assembler messages:
ebwt.h:1909: Error: invalid instruction suffix for `popcnt'
ebwt.h:1909: Error: invalid instruction suffix for `popcnt'
ebwt.h:1909: Error: invalid instruction suffix for `popcnt'
ebwt.h:1909: Error: invalid instruction suffix for `popcnt'
make[2]: *** [bowtie-build] Error 1
make[1]: *** [override_dh_auto_build] Error 2
Makefile:211: recipe for target 'bowtie-build' failed
I admit I do not have the slightest idea how to deal with issues
like this. Any (also partial help) is welcome.
Kind regards
Andreas.
On Fri, Aug 01, 2014 at 06:20:13PM +0200, Sebastian Ramacher wrote:
Source: bowtie
Version: 1.0.1-1
Severity: serious
Justification: fails to build from source
bowtie failed to build on almost every architecture. Please take a look
at https://buildd.debian.org/status/package.php?p=bowtie
Cheers
--
Sebastian Ramacher
___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756780: [Help] Need help for architecture specific code (Was: Bug#756780: bowtie: FTBFS almost everywhere)
On Mon, Aug 4, 2014 at 3:48 PM, Andreas Tille wrote: third_party/cpuid.h No idea about this problem but here is what I could figure out based on the filename and the errors, using packages.d.o, codesearch.d.n and a quick look at wikipedia. third_party/cpuid.h looks like an outdated copy of the cpuid.h header from gcc, please ask upstream to remove it and just use the normal one. The cpuid.h header seems to be only/mainly on x86 based platforms: https://packages.debian.org/search?arch=anysearchon=contentskeywords=cpuid.h If upstream was using autotools, they could detect if the header is present and only then enable the cpuid stuff. The bowtie2 package appears to only be available on *-amd64 (same issue I guess, some code seems similar): https://buildd.debian.org/status/package.php?p=bowtie2suite=unstable Looking at some valgrind code (thanks to codesearch) it seems you have to use popcntq on amd64 and popcnt on non-amd64 platforms. http://sources.debian.net/src/valgrind/latest/none/tests/amd64/sse4-64.c#L2039 BTW, what is the difference between bowtie and bowtie2? Do we need both in the archive? -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756780: [Help] Need help for architecture specific code (Was: Bug#756780: bowtie: FTBFS almost everywhere)
Hi Ben, I recently updated the bowtie package in Debian to version 1.0.1. Unfortunately this package failed to build on most of the architectures in Debian. When discussion this issue I've got the following response which I would like to bring to your attention hereby. On Mon, Aug 04, 2014 at 04:34:17PM +0800, Paul Wise wrote: On Mon, Aug 4, 2014 at 3:48 PM, Andreas Tille wrote: third_party/cpuid.h No idea about this problem but here is what I could figure out based on the filename and the errors, using packages.d.o, codesearch.d.n and a quick look at wikipedia. third_party/cpuid.h looks like an outdated copy of the cpuid.h header from gcc, please ask upstream to remove it and just use the normal one. Do you have any specific reason to use this outdated copy of cpuid.h? The cpuid.h header seems to be only/mainly on x86 based platforms: https://packages.debian.org/search?arch=anysearchon=contentskeywords=cpuid.h If upstream was using autotools, they could detect if the header is present and only then enable the cpuid stuff. It might make sense to use autotools to create the makefile and by doing so simplify porting to different architectures. Do you intend to do something like this or would you appreciate help / patches to migrate to autotools? The bowtie2 package appears to only be available on *-amd64 (same issue I guess, some code seems similar): https://buildd.debian.org/status/package.php?p=bowtie2suite=unstable Looking at some valgrind code (thanks to codesearch) it seems you have to use popcntq on amd64 and popcnt on non-amd64 platforms. http://sources.debian.net/src/valgrind/latest/none/tests/amd64/sse4-64.c#L2039 This remark boils down to the question whether it might be possible to support bowtie2 also on other architectures. BTW, what is the difference between bowtie and bowtie2? Do we need both in the archive? This question was asked by a non-biologist and I personally do also not have any background in biology. I guess that bowtie2 is not fully replacing bowtie version 1 but it might be good to know your long term plans for both versions. Kind regards and thanks for providing bowtie as free software Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
