/usr/lib/aarch64-linux-gnu/libprotobuf.a’ generated with LTO version 9.2 instead of the expected 11.0

[Heinrich Schuchardt]

When trying to build package mozc for arm64 the following error popped up:

lto1: fatal error: bytecode stream in file ‘/usr/lib/aarch64-linux-gnu/libprotobuf.a’ generated with LTO version 9.2 instead of the expected 11.0

Why does the library contain LTO information at all?

Best regards

Heinrich

[Gunnar Hjalmarsson (gunnarhj)]

This is an example build log:

https://launchpadlibrarian.net/552672484/buildlog_ubuntu-impish-arm64.mozc_2.26.4220.100+dfsg-4ubuntu3_BUILDING.txt.gz

from the impish test rebuild:

https://lists.ubuntu.com/archives/ubuntu-devel-announce/2021-August/001294.html

[Gunnar Hjalmarsson (gunnarhj)]

Thanks for reporting this, Heinrich! It looks like protobuf needs to be built with gcc-11.

[Matthias Klose (doko)]

rebuilding just hides the issue. need to find out why the lto sections are in the archive.

[Matthias Klose (doko)]

the real problem here is that the package is not stripped at all on arm64.

[Matthias Klose (doko)]

correctly stripped on other architectures, also not stripped in hirsute, so not a regression in impish.

[Matthias Klose (doko)]

3.12.4-1ubuntu1 using binutils 2.36 OK 3.12.4-1ubuntu2 BAD

[Launchpad Janitor (janitor)]

This bug was fixed in the package protobuf - 3.12.4-1ubuntu3

---------------
protobuf (3.12.4-1ubuntu3) impish; urgency=medium

  * No-change rebuild to build with gcc-11 (LP: #1939413)

 -- Gunnar Hjalmarsson <email address hidden> Thu, 12 Aug 2021 12:38:56 +0200

[Gunnar Hjalmarsson (gunnarhj)]

While the rebuild allowed for mozc to build on arm64, as Matthias pointed out there is a root cause that remains to be dealt with, so re-opening.

[dann frazier (dannf)]

The rebuild of protobuf no longer has lto information according to objdump, but the reported version certainly does. The "bad" version was built during hirsute devel, so I took a current hirsute system and systematically downgraded build-deps to the versions in the log of the "bad" build. Turns out, the relevant difference is a couple libs from elfutils: libdw1 and libelf1. If I build protobuf w/ the 0.183-6 versions, I can reproduce the problem. 0.183-8 does not (0.183-7 FTBFS, so could not be tested).

Strangely the delta between elfutils 0.183-6 and 0.183-8 appears innocuous - it all looks like packaging cleanup, no changes to upstream source.

[dann frazier (dannf)]

It would be interesting to know if the issue is due to the differences in the toolchain used to build elfutils 0.183-6 and 0.183-8. The build logs show they were 10.2.1-23ubuntu2
 and 11.2.0-1ubuntu2, respectively. If we built 2 copies of 0.183-8 in the same environment, but just varied the different gcc versions, would the problem follow the compiler?

[Alexandre Erwin Ittner (aittner)]

I was running a few test builds with different combinations of gcc, elfutils and protobuf and trying to make the build fail... but it continues working despite the older elfutils compiled with the newer gcc.

Last check was with protobuf-3.12.4-1ubuntu3 (from jammy, 4 days ago) in an impish 0.185-1build1 and then downgraded to a 0.183-8 built with 11.2.0-7ubuntu2 (from impish), but it still does not trigger the issue despite the mismatches.

I still could not find the reason.