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 >
