Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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)
signature.asc
Description: PGP signature
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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 >
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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- |
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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- |
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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 > >
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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- |
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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 > > > > > > >
Re: [ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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 > > >
[ptxdist] e2fsprogs: possibly broken when using OSELAS.Toolchain 2022.10.0
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
