Summary: | sci-physics/hepmc-2.06.09-r2 fails to compile (lto): HEPEVT_Wrapper.h:82:7: error: hepevt_ violates the C++ One Definition Rule [-Werror=odr] | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | Current packages | Assignee: | APN-Pucky <alexander> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, amadio, eschwartz93, sci-physics |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/gentoo/gentoo/pull/35656 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: | build.log |
Description
Agostino Sarubbo
2022-08-03 07:06:42 UTC
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(-) |