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

[Michael Olbrich <m.olbrich@pengutronix.de>]

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 |