[RKI-Spam-Verdacht]Maq: Strange 64bit issue

[Andreas Tille <tillea@rki.de>]

Hi,

a colleague of mine stumbled upon Maq at

   http://sourceforge.net/projects/maq/

which might be interesting for Debian Med.  It was formerly known as
Mapass2 but renamed to Maq and the readme says:

  Mapass2 is a software that builds mapping assemblies from short reads
  generated by the next-generation sequencing machines. It is particularly
  designed for Illumina-Solexa 1G Genetic Analyzer, which typically
  generates reads 25-35bp in length.

So far for the general information of the project.  I downloaded 
maq-0.6.7.tgz from

   http://sourceforge.net/project/showfiles.php?group_id=191815

and had some strange 64 bit build issues.  If you call ./configure even
on i386 system -m64 command line option is included in the Makefile which
seems to enforce a multiarch binary.  I havn't dealt with this before and
worked around some error messages like

  /usr/bin/ld: skipping incompatible /usr/lib/lib<LIB>.a when searching for -l<LIB>

messages by installing

  libc6-dev-amd64 lib64z1-dev lib64stdc++6

but finally the build process ended with

g++  -Wall -m64 -D_FASTMAP -g -O2   -o maq main.o const.o seq.o bfa.o read.o fasta2bfa.o fastq2bfq.o merge.o match_aux.o match.o sort_mapping.o assemble.o pileup.o mapcheck.o get_pos.o assopt.o aux_utils.o rbcc.o subsnp.o pair_stat.o indel_soa.o maqmap.o maqmap_conv.o altchr.o submap.o rmdup.o simulate.o genran.o indel_pe.o stdaln.o indel_call.o eland2maq.o csmap2ntmap.o break_pair.o -lm -lz 
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.1/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.1/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.1/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/i486-linux-gnu/4.3.1/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status

on a recent unstable (on testing it is the same error message excep the
gcc version string is 4.2.4 instead of 4.3.1).

Well, I guess I could circumvent all this by leaving out the unneeded -m64
switch on a 32 bit machine - but I wanted to know if there is a chance to
go with this if the authors seem to prefer this option.

Any comments to a completely 64 bit uneducated person?

Kind regards

        Andreas.

--
http://fam-tille.de