https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: sci-physics/hepmc-2.06.09-r2 fails to compile (lto). Discovered on: amd64 (internal ref: lto_tinderbox) NOTE: This machine uses lto with CFLAGS=-flto -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing Here is a bit of explanation: -Werror=lto-type-mismatch: User to find possible runtime issues in packages. It likely means the package is unsafe to build & use with LTO. For projects using the same identifier but with different types across different files, they must be fixed to be consistent across the codebase. -Werror=odr: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. C++ code must comply with the One Definition Rule (ODR) - see https://en.cppreference.com/w/cpp/language/definition#One_Definition_Rule. -Werror=strict-aliasing: Used to find possible runtime issues in packages. These bugs are a problem anyway but may be even worse when combined with LTO. Workarounds: - If upstream is friendly and still active, file a bug upstream. For emulators, codecs, games, or multimedia packages, it may be worth just applying a workaround instead, as upstreams sometimes aren't receptive to these bugs (VALID FOR ALL). - Use the new 'filter-lto' from flag-o-matic.eclass as it's likely to be unsafe with LTO (VALID FOR lto-type-mismatch - odr). - Fix it yourself if interested, of course (VALID FOR ALL). - Append-flags -fno-strict-aliasing (VALID FOR strict-aliasing). - Use memcpy() but a union is sometimes suitable too (VALID FOR strict-aliasing). - -fstrict-aliasing is implied by -O2, so this must be addressed in some form (VALID FOR strict-aliasing). See also: https://marc.info/?l=gentoo-dev&m=165639574126280&w=2
Created attachment 797155 [details] build.log build log and emerge --info
Error(s) that match a know pattern in addition to what has been reported in the summary: FAILED: lib/libHepMCfio.so.4.0.0 /var/tmp/portage/sci-physics/hepmc-2.06.09-r2/work/HepMC-2.06.09/HepMC/HEPEVT_Wrapper.h:82:7: error: ‘hepevt_’ violates the C++ One Definition Rule [-Werror=odr]
This issue is fixed in sci-physics/hepmc-3.2.7, please can it be stabilized?
I think stabilization for 3.2.6 would be better since I know at least one package that fails with 3.2.7 but works with 3.2.6. Should i open a stabreq?
That works too, yes. Please do 3.2.6 then.
Please note that, despite the name being very similar, HepMC3 is really a different project. If HepMC 2.06 fails to compile with lto, I'd suggest to filter the flags. HepMC version 2.x is at https://gitlab.cern.ch/hepmc/HepMC, but is no longer in active development. If the problem is with HepMC3, I suggest to also file the bug upstream at https://gitlab.cern.ch/hepmc/HepMC3
(In reply to APN-Pucky from comment #4) > I think stabilization for 3.2.6 would be better since I know at least one > package that fails with 3.2.7 but works with 3.2.6. Should i open a stabreq? If there's packages broken with it, it should probably be masked, not just not-stabled yet.
> it should probably be masked, not just not-stabled yet The the package I referenced is not in ::gentoo. That failing version is also not in ::sci due to that reason. It's not directly a hepmc problem, but i think it shows that 3.2.6 is more reliable/established for stabilization.
(In reply to Guilherme Amadio from comment #6) > Please note that, despite the name being very similar, HepMC3 is really a > different project. If HepMC 2.06 fails to compile with lto, I'd suggest to > filter the flags. HepMC version 2.x is at > https://gitlab.cern.ch/hepmc/HepMC, but is no longer in active development. I don't think it's remotely helpful to claim that software packaged under the same Gentoo {CAT}/{PKG} is "a different project with a similar name". Unless you think it's sufficiently different that it should be moved to its own package name instead of being merely slotted. Slotted packages and software that radically changes its entire API in addition to ABI is not exactly unheard of. This is just textbook software development and package updates taken to its logical long-term conclusion. It is sufficient to say: "both slots are needed".
(In reply to Eli Schwartz from comment #9) > I don't think it's remotely helpful to claim that software packaged under > the same Gentoo {CAT}/{PKG} is "a different project with a similar name". What I mean is that HepMC3 is a complete rewrite of HepMC (see https://hepmc.web.cern.ch/hepmc/), so since this bug was for hepmc:2, stabilizing hepmc:3 is not enough. > Unless you think it's sufficiently different that it should be moved to its > own package name instead of being merely slotted. In some distributions the two versions are provided as separate packages, but I think slots in Gentoo serve well for this purpose. > Slotted packages and software that radically changes its entire API in > addition to ABI is not exactly unheard of. This is just textbook software > development and package updates taken to its logical long-term conclusion. > > It is sufficient to say: "both slots are needed". Yes, that is what I meant. We should filter the flags on hepmc:2 to fix this bug, not just stabilize hepmc:3.
I'll look into fixing this bug then without much hope of upstreaming it.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3a9f4fcb4cf6a2403b9567e0edd83e7795faf2d9 commit 3a9f4fcb4cf6a2403b9567e0edd83e7795faf2d9 Author: Alexander Puck Neuwirth <alexander@neuwirth-informatik.de> AuthorDate: 2024-03-07 16:01:31 +0000 Commit: Guilherme Amadio <amadio@gentoo.org> CommitDate: 2024-03-08 08:59:31 +0000 sci-physics/hepmc: Filter lto flags Closes: https://bugs.gentoo.org/863284 Signed-off-by: Alexander Puck Neuwirth <alexander@neuwirth-informatik.de> Signed-off-by: Guilherme Amadio <amadio@gentoo.org> sci-physics/hepmc/hepmc-2.06.11.ebuild | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
