[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFM: transition of flint



Am 06.09.2015 um 20:14 schrieb Julien Puydt:
> Hi,
> 
> Le 06/09/2015 19:14, Tobias Hansen a écrit :
>> Am 06.09.2015 um 13:27 schrieb Julien Puydt:
>>> Hi,
>>>
>>> Le 05/09/2015 10:11, Julien Puydt a écrit :
>>>> Le 04/09/2015 21:08, Julien Puydt a écrit :
>>>>> Hmmmm... bad. If I get nothing tomorrow morning, I'll decide it's
>>>>> stuck
>>>>> and notify upstream.
>>>>
>>>> It got stuck.
>>>>
>>>> But I noticed it doesn't get stuck when I build upstream's sources
>>>> directly (ie: without the debian flags). I'm now bissecting to find out
>>>> exactly what triggers the problem.
>>>>
>>>> The transition is on hold until the matter is settled.
>>>>
>>>
>>> There's a good chance it's a compiler bug... I reported:
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798149
>>>
>>> In the mean time, what should I do? There's the option of waiting, or I
>>> could disable the hardening-flags and override the lintian warnings and
>>> still try to push the transition...
>>>
>>> Snark on #debian-science
>>>
>>
>> Hi,
>>
>> I think it's unlikely that the Debian gcc maintainers will debug this,
>> because it is still totally unclear what the problem is. It's more
>> likely that the flint maintainers would be interested to debug this
>> further. Maybe they even know about this and can tell you which
>> optimization may cause this, then one could disable only that one. It
>> would be also ok to use the optimization level that flint uses by
>> default if that solves the problem.
>>
>> Best,
>> Tobias
>>
> 
> Flint's upstream doesn't have access to an i386 box and thinks it's a
> compiler issue, so they're not very interested in debugging it.
> 
> The problem is the -O2 flag, and we get it from dpkg-buildflags... which
> is strange since I remember upstream also uses it...
> 
> I might have another idea to test!
> 
> Cheers,
> 
> Snark
> 

-O2 turns on a list of additional optimization flags compared to -O1,
see gcc(1). If one would know which one causes the problem one could
enable -O2 and diable only that one optimization. Also it would give
some hint to gcc people where the problem lies.

Best,
Tobias


Reply to: