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

Tue May 19 23:09:37 UTC 2015

Hi Alex,

Thanks for testing our package and providing us the feedback.

We will look into the getopt issue. If that is the only issue that caused problem for running Subread on ARM, I think we can fix it.

Could you also please provide us your cppcheck results? We would like to know where memory leaks occur in the code and we can then fix them.

Best regards,

Wei

On May 15, 2015, at 10:59 PM, Alex Mestiashvili wrote:

> 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.
>> ______________________________________________________________________
> 

______________________________________________________________________
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/20150520/049d4d85/attachment-0001.html>