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

[Felix Mellmann <flix@benfm.de>]

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?)

@Michael: you propose that I should resend the patch with a different 
commit message? Do you have a proposal? 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 ..

>
> Michael
>