https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-libs/libbitcoinconsensus-22.0 installs pkg-config files with mismatched Version. 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 794969 [details] build.log build log and emerge --info
Any explanation why this is considered a bug? (Version in the .pc is 22.0.0)
I think this case is borderline. A wrong version in the .pc file would usually breaks dependency discovery. However, in this case we have 22.0.0 in the .pc file and 22.0 in the ebuild. But in any case, the ebuild version should match the version the software identifies as. So I would suggest to rename the ebuild to libbitcoinconsensus-22.0.0.
But upstream version of this release, as seen in https://github.com/bitcoin/bitcoin/releases, is just "22.0". Majority of these "... installs pkg-config files with mismatched Version" reports are about nonproblems. For different packages, different components of version have different meaning and relevance to API/ABI stability. Some packages have deliberately different version of release and version of library/libraries (media-video/ffmpeg (bug #859478) is good example). I think that this "QA check" should be much reduced in scope, e.g. to detect missing/empty Version field.
It seems likely that at some point, there will be a 2x.y.z version, so I'm not absolutely against adding a .0 here, but I don't think we have a reason to rename current versions.
You can just add QA_PKGCONFIG_VERSION="${PV}.0" in your ebuild file to silence this issue eventually.
See https://bugs.gentoo.org/857654#c1. This check has been dropped in portage-3.0.35 because of false positives, usually relating to SONAME versioning not corresponding to ${PV}. It may be restored at a later time in an opt-in fashion (either for users/developers to set in e.g. make.conf, or for ebuilds to enable when upstream is known to make errors (possibly could be by setting QA_PKGCONFIG_VERSION?)). Apologies for the noise until now. It was an experiment and while some legitimate bugs were found, it was too noisy and that's unfair to developers.
