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

Sat Sep 5 10:19:43 UTC 2015

Dear Wei,

thank you a lot for the update! I'll try to package the new version next
week.

Best regards,
Alex

On 09/04/2015 03:27 AM, Wei Shi wrote:
> 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/20150905/865538be/attachment-0001.html>