<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Dear Wei, <br>
<br>
thank you for the quick answer.<br>
<br>
On 05/12/2015 01:59 AM, Wei Shi wrote:<br>
</div>
<blockquote
cite="mid:F0200EB6-835B-4F01-AFAA-1D2BF4E9048E@wehi.edu.au"
type="cite">Hi Alex,
<div><br>
</div>
<div>We have tested subread on both 32-bit and 64-bit Intel and
AMD platforms and it works fine (the gcc flags you mentioned
were all included). So I do not know what caused the
installation failure. Maybe you can show us the errors you have
encountered?</div>
</blockquote>
<br>
I was not correct in the last email, the failure on i386 was related
to the debian specific part of the build process.<br>
So both AMD64 and i386 are fine.<br>
The full build logs are located here:
<a class="moz-txt-link-freetext" href="https://buildd.debian.org/status/logs.php?pkg=subread">https://buildd.debian.org/status/logs.php?pkg=subread</a><br>
<br>
Regarding the -mtune option, My understanding is that tuning for a
specific CPU shouldn't be used for a <br>
binary package which can be used on a wide range of CPUs.<br>
Currently I removed -mtune completely, but maybe -mtune=generic
should be used instead of -mtune=core2.<br>
<br>
"generic" <br>
Produce code optimized for the most common IA32/AMD64/EM64T
processors.<br>
If you know the CPU on which your code will run, then you should
use
the <br>
corresponding <samp><span class="option">-mtune</span></samp> or <samp><span
class="option">-march</span></samp> option instead of
<samp><span class="option">-mtune=generic</span></samp>. <br>
But, if you do not know exactly what CPU users
of your application will have, <br>
then you should use this option. <br>
<br>
<a class="moz-txt-link-freetext" href="https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html">https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html</a><br>
<br>
The -msse and -msse2 flags are enabled by default for x86-64
compiler, so it should be no problem to strip them, <br>
and AFAIK SSE also implies support for MMX, so -mmmx flag is not
needed too.<br>
<br>
<blockquote
cite="mid:F0200EB6-835B-4F01-AFAA-1D2BF4E9048E@wehi.edu.au"
type="cite">
<div>Currently, Subread only supports AMD and Intel architectures
and we do not have a plan to support other platforms such as
ARM.</div>
</blockquote>
<br>
I see, In such case I'll limit the architectures for the package to
the ones where it builds successfully and passes the tests.<br>
<br>
Just for your information, I tried to fix the getopt issue by
defining "c" as int instead of char.<br>
The binaries were build successfully on ARM and other architectures,
but the tests fail, you can see the results here:<br>
<br>
<a class="moz-txt-link-freetext" href="https://buildd.debian.org/status/logs.php?pkg=subread&ver=1.4.6-p2%2Bdfsg-3&suite=experimental">https://buildd.debian.org/status/logs.php?pkg=subread&ver=1.4.6-p2%2Bdfsg-3&suite=experimental</a><br>
<br>
Also the cppcheck reveals a lot of memory leaks in the code.<br>
<br>
Best regards, <br>
Alex<br>
<br>
<blockquote
cite="mid:F0200EB6-835B-4F01-AFAA-1D2BF4E9048E@wehi.edu.au"
type="cite">
<div><br>
<div>
<div>On May 11, 2015, at 5:34 PM, Alex Mestiashvili wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div text="#000000" bgcolor="#FFFFFF"> Dear Dr. Wei Shi, <br>
<br>
Debian supports many CPU architectures and building of
subread failed on some of these architectures.<br>
<br>
1. Due to quite specific -mtune and -mmmx -msse* gcc
flags, subread failed to build almost on any architecture
except amd64.<br>
This issue was fixed by removing -mtune and -mmmx -msse*
flags from the src/Makefile.Linux. <br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://anonscm.debian.org/cgit/debian-med/subread.git/tree/debian/patches/gcc_flags_cleanup.patch">http://anonscm.debian.org/cgit/debian-med/subread.git/tree/debian/patches/gcc_flags_cleanup.patch</a><br>
<br>
2. We still have an issue, now with exactSNP, please see
the bug report below.<br>
<br>
Thank you, <br>
Alex<br>
<div class="moz-forward-container"><br>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Subject: </th>
<td>[Debian-med-packaging] Bug#784929: subread:
FTBFS on arm64, armel, armhf, ...</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Resent-Date: </th>
<td>Sun, 10 May 2015 19:54:01 +0000</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Resent-From: </th>
<td>Edmund Grimley Evans <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:edmund.grimley.evans@gmail.com"><edmund.grimley.evans@gmail.com></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Resent-To: </th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:debian-bugs-dist@lists.debian.org">debian-bugs-dist@lists.debian.org</a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Resent-CC: </th>
<td>Debian Med Packaging Team <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:debian-med-packaging@lists.alioth.debian.org"><debian-med-packaging@lists.alioth.debian.org></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Date: </th>
<td>Sun, 10 May 2015 20:51:41 +0100</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">From: </th>
<td>Edmund Grimley Evans <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:edmund.grimley.evans@gmail.com"><edmund.grimley.evans@gmail.com></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">Reply-To: </th>
<td>Edmund Grimley Evans <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:edmund.grimley.evans@gmail.com"><edmund.grimley.evans@gmail.com></a>,
<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:784929@bugs.debian.org">784929@bugs.debian.org</a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE"
align="RIGHT">To: </th>
<td><a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:submit@bugs.debian.org">submit@bugs.debian.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>Source: subread
Version: 1.4.6-p2+dfsg-2
It failed to build on several architectures:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://buildd.debian.org/status/package.php?p=subread&suite=sid">https://buildd.debian.org/status/package.php?p=subread&suite=sid</a>
There seems to be a problem with (unsigned) char. See this file, for
example:
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://sources.debian.net/src/subread/1.4.6-p2%2Bdfsg-2/src/SNPCalling.c/">https://sources.debian.net/src/subread/1.4.6-p2%2Bdfsg-2/src/SNPCalling.c/</a>
This line:
while ((c = getopt_long (argc, argv, "7:N:a:i:g:o:bQ:p:f:n:r:x:w:s:t:T:v4",snp_long_options, &optindex))!=-1)
The function getopt_long returns int, but the value is assigned to a
char c, which is unsigned on ARM architectures, so it will never be
equal to -1. That is probably the immediate cause of the failure.
However, there may be other char-related problems in there. I noticed,
for example, that mask_snp_bitmap may be incorrect according to the C
standard (signed overflow).
_______________________________________________
Debian-med-packaging mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Debian-med-packaging@lists.alioth.debian.org">Debian-med-packaging@lists.alioth.debian.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging">http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging</a>
</pre>
<br>
</div>
<br>
</div>
</blockquote>
</div>
<br>
</div>
<br clear="all">
______________________________________________________________________<br>
The information in this email is confidential and intended solely
for the addressee.<br>
You must not disclose, forward, print or use it without the
permission of the sender.<br>
______________________________________________________________________<br>
</blockquote>
<br>
</body>
</html>