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

[Andreas Tille]

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


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Mon, Jul 07, 2008 at 04:09:56PM +0200, Andreas Tille a écrit :
>
> a colleague of mine stumbled upon Maq at
>
>    http://sourceforge.net/projects/maq/

> /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).
 
> Any comments to a completely 64 bit uneducated person?

Hi Andreas,

you may have more luck on the debian-amd64 mailing list…

Anyway, Maq had a nice advertisement in a recent review published in
Genome Research, and it is therefore definitely one of the programs we
must add to our collection before the end of the year. I just imported
a rudimentary packaging in our subversion repository. Unfortunately, the
binary building also fails on my machine (powerpc):

g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o pair_stat.o pair_stat.ccg++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o indel_soa.o indel_soa.ccindel_soa.cc: In function ‘void fill_counter(bit32_t*, int, nst_bfa1_t*, void*)’:
indel_soa.cc:42: warning: suggest parentheses around + or - inside shift
indel_soa.cc:56: warning: suggest parentheses around + or - inside shift
cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c maqmap.c
cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c maqmap_conv.c
g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o altchr.o altchr.cc
cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c submap.c
g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o rmdup.o rmdup.cc
cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c simulate.c
simulate.c: In function ‘simustat_core’:
simulate.c:374: internal compiler error: in expand_expr_real_1, at expr.c:9199
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.3/README.Bugs> for instructions.
make[2]: *** [simulate.o] Erreur 1
make[2]: quittant le répertoire « /home/charles/src/maq-0.6.7 »
make[1]: *** [all] Erreur 2
make[1]: quittant le répertoire « /home/charles/src/maq-0.6.7 »
make: *** [debian/stamp-makefile-build] Erreur 2
dpkg-buildpackage: échec: debian/rules build a produit une erreur de sortie de type 2
debuild: fatal error at line 1319:
dpkg-buildpackage -rfakeroot -D -us -uc failed

Have a nice day,

--
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Mon, 7 Jul 2008, Charles Plessy wrote:

> Anyway, Maq had a nice advertisement in a recent review published in
> Genome Research, and it is therefore definitely one of the programs we
> must add to our collection before the end of the year. I just imported
> a rudimentary packaging in our subversion repository. Unfortunately, the
> binary building also fails on my machine (powerpc):

OK - you might have noticed that I added some info to debian/control
and I'll add it to our tasks.

> g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o pair_stat.o pair_stat.ccg++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o indel_soa.o indel_soa.ccindel_soa.cc: In function ?void fill_counter(bit32_t*, int, nst_bfa1_t*, void*)?:
> indel_soa.cc:42: warning: suggest parentheses around + or - inside shift
> indel_soa.cc:56: warning: suggest parentheses around + or - inside shift
> cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c maqmap.c
> cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c maqmap_conv.c
> g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o altchr.o altchr.cc
> cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c submap.c
> g++ -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c -o rmdup.o rmdup.cc
> cc -DHAVE_CONFIG_H -I.     -Wall -m64 -D_FASTMAP -g -O2 -g -Wall -O2 -c simulate.c
> simulate.c: In function ?simustat_core?:
> simulate.c:374: internal compiler error: in expand_expr_real_1, at expr.c:9199

Ups, that's several steps earlier in compile process.  Will you investigate
in this on powerpc list?  I think I'll try the issue on debian-devel (trusting
that there are enough people with apropriate knowledge).

Thanks for your input

         Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Mon, 7 Jul 2008, Charles Plessy wrote:

> Anyway, Maq had a nice advertisement in a recent review published in
> Genome Research, and it is therefore definitely one of the programs we
> must add to our collection before the end of the year. I just imported
> a rudimentary packaging in our subversion repository.

OK, seems we have good chances considering the progress we made in SVN.
The remaining issues are:

    1. Renaming *.pl files
       Lintian warns about files /usr/bin/*.pl (script-with-language-extension)
       and normally it would be cheap to rename these but in this specific
       case we have a binary map and a script map.pl and thus we can only
       have one of them names maq.

       Moreover I'm absolutely unclear about the role these *.pl files
       are playing.  They are not documented and I wonder whether they
       should be put into /usr/share/maq while adapting the path apropriately.
       But no *.c file seems to refer to any of these scripts and the
       assumption that maq binary is calling the scripts seems to be
       wrong.

       Another question is why only half of the scripts are installed
       by Makefile.am:bin_SCRIPTS ...

    2. Documenting Perl scripts
       We have some binary-without-manpage warnigs and I would like to
       remove these - but as I mentioned above I have no idea what these
       scripts are doing.  SO I feel unable to write a reasonable man
       page.

> Unfortunately, the binary building also fails on my machine (powerpc):

Is this solved now by the Build-Depends I used according to the hint
on debian-devel?

Kind regards

         Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Charles Plessy-12]

Le Tue, Jul 08, 2008 at 10:02:35AM +0200, Andreas Tille a écrit :
>
>    1. Renaming *.pl files
>       Lintian warns about files /usr/bin/*.pl
>       (script-with-language-extension)
>       and normally it would be cheap to rename these but in this specific
>       case we have a binary map and a script map.pl and thus we can only
>       have one of them names maq.


>    2. Documenting Perl scripts
>       We have some binary-without-manpage warnigs and I would like to
>       remove these - but as I mentioned above I have no idea what these
>       scripts are doing.  SO I feel unable to write a reasonable man
>       page.

Hi Andreas,

from the maq manpage, it seems that users are expected to be able to run
maq or maq.pl in command line, so they definitely will have to go to
/usr/bin. maq.pl is a pipeline that calls many maq programs (themselves
called through /usr/bin maq). If this is a good reason for keeping the
.pl extension, we can write a Lintian override, otherwise let's discuss
the issue with Upstream. Same for the undocumented Perl scripts: let's
write a minimal POD manpage and submit the diff as a bug report in
SourceForge.

> >Unfortunately, the binary building also fails on my machine (powerpc):
>
> Is this solved now by the Build-Depends I used according to the hint
> on debian-devel?

Unfortunately it still crashes. I will ask on debian-powerpc and keep
you informed.

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille]

On Tue, 8 Jul 2008, Charles Plessy wrote:

> from the maq manpage, it seems that users are expected to be able to run
> maq or maq.pl in command line, so they definitely will have to go to
> /usr/bin. maq.pl is a pipeline that calls many maq programs (themselves
> called through /usr/bin maq). If this is a good reason for keeping the
> .pl extension, we can write a Lintian override,

Well, I don't mind about an override if it makes sense.  If the docs say
"call maq.pl" we should not change the name - but I have not found docs
saying this explicitely.

> otherwise let's discuss
> the issue with Upstream. Same for the undocumented Perl scripts: let's
> write a minimal POD manpage and submit the diff as a bug report in
> SourceForge.

Would you take over this job because I'm not very comfortable with POD?
Moreover once you are at it in their bug tracker I - I'm curious about
the other scripts not automatically installed by the installer.

> Unfortunately it still crashes. I will ask on debian-powerpc and keep
> you informed.

While I can perfectly build a reasonable package the executable fails:

$ /usr/bin/maq
-bash: /usr/bin/maq: cannot execute binary file
$ ldd /usr/bin/maq
ldd: exited with unknown exit code (126)

I expect another 64 bit issue and will continue asking on debian-devel.

Kind regards

           Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...