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

Wei Shi shi at wehi.EDU.AU
Fri Sep 4 01:27:19 UTC 2015 

Dear Alex,

Hope you are well. Just let you know that we have included complete documentation in our latest release 1.4.6-p5.

Best wishes,

Wei



On May 22, 2015, at 7:08 PM, Alex Mestiashvili wrote:

> Hi Wei, 
> 
> On 05/20/2015 01:09 AM, Wei Shi wrote:
>> 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.
> 
> The good news - ARM issues are solved by adding -fsigned-char to CCFLAGS.
> In this case subread works on architectures where char is by default unsigned such as armel, armhf and so on.
> And in this case there is no need to patch getopt.
> 
> Though there are still problems on powerpc, mips and s390x:
> - subjunc test return Segmentation fault, 
> - exactSNP test complains that it can not read the file 
> 
> here is the output:
> exactSNP FEOF 0!
> SAM file does not exist or is not accessible: 'data/test-in.BAM'
> 
>> 
>> 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.
> 
> Please see the attachment for the cppcheck output.
> 
> Thank you, 
> Alex
> 
>> 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.
>> ______________________________________________________________________
> 
> <cppcheck4subread.txt>


______________________________________________________________________
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/20150904/3512ef48/attachment-0001.html>

More information about the Debian-med-packaging mailing list