[Debian-med-packaging] Bug#784929: subread: FTBFS on arm64, armel, armhf, ...

[Alex Mestiashvili]

Dear Wei,

thank you for the quick answer.

On 05/12/2015 01:59 AM, Wei Shi wrote:
> Hi Alex,
>
> 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?

I was not correct in the last email, the failure on i386 was related to 
the debian specific part of the build process.
So both AMD64 and i386 are fine.
The full build logs are located here: 
https://buildd.debian.org/status/logs.php?pkg=subread

Regarding the -mtune option, My understanding is that tuning for a 
specific CPU shouldn't be used for a
binary package which can be used on a wide range of CPUs.
Currently I removed -mtune completely, but maybe -mtune=generic should 
be used instead of  -mtune=core2.

  "generic"
  Produce code optimized for the most common IA32/AMD64/EM64T processors.
  If you know the CPU on which your code will run, then you should use the
  corresponding -mtune or -march option instead of -mtune=generic.
  But, if you do not know exactly what CPU users of your application 
will have,
  then you should use this option.

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html

The -msse and -msse2 flags are enabled by default for x86-64 compiler, 
so it should be no problem to strip them,
and AFAIK SSE also implies support for MMX, so -mmmx flag is not needed too.

> Currently, Subread only supports AMD and Intel architectures and we do 
> not have a plan to support other platforms such as ARM.

I see, In such case I'll limit the architectures for the package to the 
ones where it builds successfully and passes the tests.

Just for your information, I tried to fix the getopt issue by defining 
"c" as int instead of char.
The binaries were build successfully on ARM and other architectures, but 
the tests fail, you can see the results here:

  https://buildd.debian.org/status/logs.php?pkg=subread&ver=1.4.6-p2%2Bdfsg-3&suite=experimental

Also the cppcheck reveals a lot of memory leaks in the code.

Best regards,
Alex

>
> On May 11, 2015, at 5:34 PM, Alex Mestiashvili wrote:
>
>> Dear Dr. Wei Shi,
>>
>> Debian supports many CPU architectures and building of subread failed 
>> on some of these architectures.
>>
>> 1. Due to quite specific -mtune and -mmmx -msse* gcc flags, subread 
>> failed to build almost on any architecture except amd64.
>> This issue was fixed by removing -mtune and -mmmx -msse* flags from 
>> the src/Makefile.Linux.
>> http://anonscm.debian.org/cgit/debian-med/subread.git/tree/debian/patches/gcc_flags_cleanup.patch
>>
>> 2. We still have an issue, now with exactSNP, please see the bug 
>> report below.
>>
>> Thank you,
>> Alex
>>
>>
>> -------- Forwarded Message --------
>> Subject: 	[Debian-med-packaging] Bug#784929: subread: FTBFS on arm64, 
>> armel, armhf, ...
>> Resent-Date: 	Sun, 10 May 2015 19:54:01 +0000
>> Resent-From: 	Edmund Grimley Evans <edmund.grimley.evans at gmail.com>
>> Resent-To: 	debian-bugs-dist at lists.debian.org
>> Resent-CC: 	Debian Med Packaging Team 
>> <debian-med-packaging at lists.alioth.debian.org>
>> Date: 	Sun, 10 May 2015 20:51:41 +0100
>> From: 	Edmund Grimley Evans <edmund.grimley.evans at gmail.com>
>> Reply-To: 	Edmund Grimley Evans <edmund.grimley.evans at gmail.com>, 
>> 784929 at bugs.debian.org
>> To: 	submit at bugs.debian.org
>>
>>
>>
>> Source: subread
>> Version: 1.4.6-p2+dfsg-2
>>
>> It failed to build on several architectures:
>>
>> https://buildd.debian.org/status/package.php?p=subread&suite=sid
>>
>> There seems to be a problem with (unsigned) char. See this file, for
>> example:
>>
>> https://sources.debian.net/src/subread/1.4.6-p2%2Bdfsg-2/src/SNPCalling.c/
>>
>> 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
>> Debian-med-packaging at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>>
>>
>
>
> ______________________________________________________________________
> The information in this email is confidential and intended solely for 
> the addressee.
> You must not disclose, forward, print or use it without the permission 
> of the sender.
> ______________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20150515/93523407/attachment.html>