mailarchive of the ptxdist mailing list
 help / color / mirror / Atom feed
* [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
@ 2022-11-13 17:32 Felix Mellmann
  2022-11-13 21:07 ` Christian Melki
  2022-11-16  7:17 ` Michael Olbrich
  0 siblings, 2 replies; 12+ messages in thread
From: Felix Mellmann @ 2022-11-13 17:32 UTC (permalink / raw)
  To: ptxdist

Hi everyone,

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.


Best regards,

Felix





^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-13 17:32 [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0 Felix Mellmann
@ 2022-11-13 21:07 ` Christian Melki
  2022-11-14  9:05   ` Ladislav Michl
  2022-11-16  7:17 ` Michael Olbrich
  1 sibling, 1 reply; 12+ messages in thread
From: Christian Melki @ 2022-11-13 21:07 UTC (permalink / raw)
  To: Felix Mellmann; +Cc: ptxdist

Hi Felix,

On 11/13/22 18:32, Felix Mellmann wrote:
> Hi everyone,
> 
> 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".
> 

First things first.
So it looks like e2fsprogs is mixing compilers and archs here?
That would be my guess to what's behind the 11.2 / 11.3 error.

But probably more importantly,
enable-lto looks like a misconfiguration to me.
Maybe if it was controlled by a global.
And even then one would probably have to weed out a lot of compile
failures given the rocky history of LTO over a lot of stuff.
I suggest you disable it and submit a patch.

Regards,
Christian

> As I'm no expert at this level, I hope anyone could put some hints about 
> the issue.
> 
> 
> Best regards,
> 
> Felix
> 
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-13 21:07 ` Christian Melki
@ 2022-11-14  9:05   ` Ladislav Michl
  0 siblings, 0 replies; 12+ messages in thread
From: Ladislav Michl @ 2022-11-14  9:05 UTC (permalink / raw)
  To: ptxdist, christian.melki; +Cc: Felix Mellmann

On Sun, Nov 13, 2022 at 10:07:48PM +0100, Christian Melki wrote:
> Hi Felix,
> 
> On 11/13/22 18:32, Felix Mellmann wrote:
> > Hi everyone,
> > 
> > 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".
> > 
> 
> First things first.
> So it looks like e2fsprogs is mixing compilers and archs here?
> That would be my guess to what's behind the 11.2 / 11.3 error.
> 
> But probably more importantly,
> enable-lto looks like a misconfiguration to me.
> Maybe if it was controlled by a global.
> And even then one would probably have to weed out a lot of compile
> failures given the rocky history of LTO over a lot of stuff.
> I suggest you disable it and submit a patch.

I second that. Also see commit 'debian: stop using LTO (link-time optimization)'
https://github.com/tytso/e2fsprogs/commit/cfb073a4d4f37768b0be81660054044162dd8766

Regards,
	l.

> Regards,
> Christian
> 
> > As I'm no expert at this level, I hope anyone could put some hints about 
> > the issue.
> > 
> > 
> > Best regards,
> > 
> > Felix
> > 
> > 
> > 
> 



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-13 17:32 [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0 Felix Mellmann
  2022-11-13 21:07 ` Christian Melki
@ 2022-11-16  7:17 ` Michael Olbrich
  2022-11-16 14:08   ` Felix Mellmann
  1 sibling, 1 reply; 12+ messages in thread
From: Michael Olbrich @ 2022-11-16  7:17 UTC (permalink / raw)
  To: Felix Mellmann; +Cc: ptxdist

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.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-16  7:17 ` Michael Olbrich
@ 2022-11-16 14:08   ` Felix Mellmann
  2022-11-16 17:40     ` Christian Melki
  0 siblings, 1 reply; 12+ messages in thread
From: Felix Mellmann @ 2022-11-16 14:08 UTC (permalink / raw)
  To: ptxdist


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.

>
> Michael


Felix




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-16 14:08   ` Felix Mellmann
@ 2022-11-16 17:40     ` Christian Melki
  2022-11-17  7:45       ` Michael Olbrich
  0 siblings, 1 reply; 12+ messages in thread
From: Christian Melki @ 2022-11-16 17:40 UTC (permalink / raw)
  To: Felix Mellmann, Michael Olbrich; +Cc: ptxdist

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.
Regardless if it's working or not.
A global for LTO would be much better.

>>
>> Michael
> 
> 
> Felix
> 
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-16 17:40     ` Christian Melki
@ 2022-11-17  7:45       ` Michael Olbrich
  2022-11-17 14:51         ` Felix Mellmann
  2022-11-17 14:52         ` Felix Mellmann
  0 siblings, 2 replies; 12+ messages in thread
From: Michael Olbrich @ 2022-11-17  7:45 UTC (permalink / raw)
  To: Christian Melki; +Cc: ptxdist, Felix Mellmann

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.

Michael

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-17  7:45       ` Michael Olbrich
@ 2022-11-17 14:51         ` Felix Mellmann
  2022-11-17 14:52         ` Felix Mellmann
  1 sibling, 0 replies; 12+ messages in thread
From: Felix Mellmann @ 2022-11-17 14:51 UTC (permalink / raw)
  To: ptxdist

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
>



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-17  7:45       ` Michael Olbrich
  2022-11-17 14:51         ` Felix Mellmann
@ 2022-11-17 14:52         ` Felix Mellmann
  2022-11-17 15:05           ` Michael Olbrich
  2022-11-17 17:50           ` Alexander Dahl
  1 sibling, 2 replies; 12+ messages in thread
From: Felix Mellmann @ 2022-11-17 14:52 UTC (permalink / raw)
  To: ptxdist

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
>



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-17 14:52         ` Felix Mellmann
@ 2022-11-17 15:05           ` Michael Olbrich
  2022-11-17 17:15             ` Christian Melki
  2022-11-17 17:50           ` Alexander Dahl
  1 sibling, 1 reply; 12+ messages in thread
From: Michael Olbrich @ 2022-11-17 15:05 UTC (permalink / raw)
  To: Felix Mellmann; +Cc: ptxdist

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

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

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-17 15:05           ` Michael Olbrich
@ 2022-11-17 17:15             ` Christian Melki
  0 siblings, 0 replies; 12+ messages in thread
From: Christian Melki @ 2022-11-17 17:15 UTC (permalink / raw)
  To: Michael Olbrich; +Cc: ptxdist, Felix Mellmann

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
> 




^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
  2022-11-17 14:52         ` Felix Mellmann
  2022-11-17 15:05           ` Michael Olbrich
@ 2022-11-17 17:50           ` Alexander Dahl
  1 sibling, 0 replies; 12+ messages in thread
From: Alexander Dahl @ 2022-11-17 17:50 UTC (permalink / raw)
  To: Felix Mellmann; +Cc: ptxdist

[-- Attachment #1: Type: text/plain, Size: 4231 bytes --]

Hei hei,

Am Thu, Nov 17, 2022 at 03:52:18PM +0100 schrieb Felix Mellmann:
> 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 ..

According to `git blame rules/e2fsprogs.make` that option was added
with commit 471f5e0889e7 ("e2fsprogs: version bump 1.44.4 -> 1.44.6")
in 2020, but the commit message is rather generic.

Greets
Alex

-- 
/"\ ASCII RIBBON | »With the first link, the chain is forged. The first
\ / CAMPAIGN     | speech censured, the first thought forbidden, the
 X  AGAINST      | first freedom denied, chains us all irrevocably.«
/ \ HTML MAIL    | (Jean-Luc Picard, quoting Judge Aaron Satie)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2022-11-18  9:02 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-13 17:32 [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0 Felix Mellmann
2022-11-13 21:07 ` Christian Melki
2022-11-14  9:05   ` Ladislav Michl
2022-11-16  7:17 ` Michael Olbrich
2022-11-16 14:08   ` Felix Mellmann
2022-11-16 17:40     ` Christian Melki
2022-11-17  7:45       ` Michael Olbrich
2022-11-17 14:51         ` Felix Mellmann
2022-11-17 14:52         ` Felix Mellmann
2022-11-17 15:05           ` Michael Olbrich
2022-11-17 17:15             ` Christian Melki
2022-11-17 17:50           ` Alexander Dahl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox