Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0

[Christian Melki <christian.melki@t2data.com>]

On 11/17/22 16:05, Michael Olbrich wrote:
> On Thu, Nov 17, 2022 at 03:52:18PM +0100, Felix Mellmann wrote:
>> On 17.11.22 08:45, Michael Olbrich wrote:
>>> On Wed, Nov 16, 2022 at 06:40:02PM +0100, Christian Melki wrote:
>>>> On 11/16/22 15:08, Felix Mellmann wrote:
>>>>> On 16.11.22 08:17, Michael Olbrich wrote:
>>>>>> On Sun, Nov 13, 2022 at 06:32:01PM +0100, Felix Mellmann wrote:
>>>>>>> I've just run into a linker problem when building e2fsprogs 1.46.5 using
>>>>>>> OSELAS.Toolchain 2022.10.0 (arm-v7a-linux-gnueabihf):
>>>>>>>
>>>>>>>
>>>>>>> -------------------------
>>>>>>> target: e2fsprogs.compile
>>>>>>> -------------------------
>>>>>>>
>>>>>>> make: Entering directory
>>>>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5'
>>>>>>> cd ./util ; make subst
>>>>>>> make[1]: Entering directory
>>>>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5/util'
>>>>>>>       CREATE dirpaths.h
>>>>>>>       CC subst.c
>>>>>>>       LD subst
>>>>>>> lto1: fatal error: bytecode stream in file 'subst.o' generated with LTO
>>>>>>> version 11.2 instead of the expected 11.3
>>>>>>> compilation terminated.
>>>>>>> lto-wrapper: fatal error: /usr/bin/gcc returned 1 exit status
>>>>>>> compilation terminated.
>>>>>>> /usr/bin/ld: error: lto-wrapper failed
>>>>>>> collect2: error: ld returned 1 exit status
>>>>>>> make[1]: *** [Makefile:369: subst] Error 1
>>>>>>> make[1]: Leaving directory
>>>>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5/util'
>>>>>>> make: *** [Makefile:194: util/subst] Error 2
>>>>>>> make: Leaving directory
>>>>>>> '/PTXdist/BSP/platform-imx6/build-target/e2fsprogs-1.46.5'
>>>>>>> make: ***
>>>>>>> [/usr/local/lib/ptxdist-2022.11.0/rules/post/ptxd_make_world_compile.make:20:
>>>>>>> /PTXdist/BSP/platform-imx6/state/e2fsprogs.compile] Error 2
>>>>>>>
>>>>>>> The error vanishes if ./configure is called with "--disable-lto" instead of
>>>>>>> "--enable-lto".
>>>>>>>
>>>>>>> As I'm no expert at this level, I hope anyone could put some hints about the
>>>>>>> issue.
>>>>>> Is this a clean build? I've not seen this here with the same toolchain and
>>>>>> the error looks like you're mixing compiler versions.
>>>>> It was a clean build, yes. But finally - ccache messed it up. After
>>>>> clearing the cache the build was successful.
>>>>>
>>>>> Well I should loose my trust in ccache ... Please drop my patch.
>>>>>
>>>> I still think that LTO should not be enabled per project like that.
>>> It's a good point. So I may apply the patch with a modified commit message.
>>> I'm not sure yet.
>>>
>>>> Regardless if it's working or not.
>>>> A global for LTO would be much better.
>>> Sneaking it in via compiler wrappers does not work. It breaks quite a few
>>> packages (I tried that some time ago). But maybe a global option that
>>> selected packages can use to enable it conditionally.
>>
>> Grepping through the packages reveals, that 8 packages explicitly disable
>> LTO and only e2fsprogs enables LTO. For the rest I'm unsure about the
>> defaults. So what should a global LTO option look like and what should be
>> the consequences? (i.e. replace all the enable/disable-lto with the global
>> option? Enforce a setting for all packages not configuring a default?)
> 

Maybe an optimization category in platformconfig with globals?
Ptxdist has hardening and "other". It sure could fit in the other category.
But I feel there are probably a few optimization knobs that could
deserve a global anyway.

Christian

> Probably something like that. The problem is that, in my experience,
> packages can fail to build depending on the compiler version and the target
> architecture. So it will be hard to get something that even builds
> reliably. I think we will only enable it for packages where the possible
> performance benefit is actually useful.
> 
>> @Michael: you propose that I should resend the patch with a different commit
>> message? Do you have a proposal?
> 
> Don't bother. I'll come up with something and add it to the patch.
> 
>> I really don't have a clue why LTO is
>> enabled for this peculiar package and its consequences and I unfortunately
>> run into a random ccache issue ..
> 
> I'm pretty sure that it was only accidentally enabled instead of disabling
> it when the option was added to the upstream package. And I missed it when
> I applied the patch.
> 
> The interesting question is, why did ccache reuse the result in the first
> place? I don't think it should do that for results created by a different
> compiler version. And is there something in ptxdist that we can do to help
> ccache make the correct decision?
> 
> Michael
>