There are multiple deficiencies in the sys-libs/libbacktrace-1.0_p20220226 ebuild in the main Gentoo repository: * Lack of keywords. Even ~x86 is missing! * No IUSE="static-libs". * Installs a libtool archive (.la) file. * Neither builds nor installs a shared library. * Outdated snapshot. Recommend replacing the ebuild in the tree with the one from the Bitcoin overlay (which I authored): https://gitlab.com/bitcoin/gentoo/-/raw/master/sys-libs/libbacktrace/libbacktrace-1.0_p20220709.ebuild
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1defca4f16f7668b5c389c8f9760355aa932778e commit 1defca4f16f7668b5c389c8f9760355aa932778e Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2022-10-02 18:50:05 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2022-10-02 18:51:32 +0000 sys-libs/libbacktrace: Version bump based on work by Matt Whitlock Closes: https://bugs.gentoo.org/870454 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> sys-libs/libbacktrace/Manifest | 1 + .../libbacktrace-1.0_p20220709-teststatic.patch | 287 +++++++++++++++++++++ .../libbacktrace/libbacktrace-1.0_p20220709.ebuild | 45 ++++ 3 files changed, 333 insertions(+)
Thanks. That addresses almost all of my issues. However, why remove all of the keywords except ~amd64? I am pretty sure that libbacktrace is not specific to the x86_64 architecture, and I have a reverse dependency that needs libbacktrace and has keywords ~arm, ~arm64, ~mips, ~ppc, and ~x86 in addition to ~amd64. I don't have hardware in all of those architectures to test with, but I could test on arm, mips, and x86 if you require a positive report before you'll consent to adding those keywords.
According to reading of configure.ac and Makefile.am: - Usage of 'xz' executable (from BROOT): https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/configure.ac#L518: > AC_CHECK_PROG(XZ, xz, xz) https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/Makefile.am#L514: > $(XZ) $<.mdbg - Linking against liblzma.so library (from EROOT) https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/configure.ac#L526-L528: > AC_CHECK_LIB([lzma], [lzma_auto_decoder], > [AC_DEFINE(HAVE_LIBLZMA, 1, [Define if -llzma is available.])]) > AM_CONDITIONAL(HAVE_LIBLZMA, test "$ac_cv_lib_lzma_lzma_auto_decoder" = yes) https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/Makefile.am#L532-L535: > if HAVE_LIBLZMA > xztest_LDADD += -llzma > xztest_alloc_LDADD += -llzma > endif - Linking against libz.so library (from EROOT): https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/configure.ac#L480-L482: > AC_CHECK_LIB([z], [compress], > [AC_DEFINE(HAVE_ZLIB, 1, [Define if -lz is available.])]) > AM_CONDITIONAL(HAVE_ZLIB, test "$ac_cv_lib_z_compress" = yes) https://github.com/ianlancetaylor/libbacktrace/blob/8602fda64e78f1f46563220f2ee9f7e70819c51d/Makefile.am#L358-L361: > if HAVE_ZLIB > ztest_LDADD += -lz > ztest_alloc_LDADD += -lz > endif This means that correct BDEPEND and DEPEND would be: BDEPEND=" test? ( app-arch/xz-utils ) " DEPEND=" test? ( app-arch/xz-utils sys-libs/zlib ) " Regarding KEYWORDS, previous version available in Gentoo (libbacktrace-1.0_p20220226) has only KEYWORDS="~amd64", so by policy this value of KEYWORDS should have been copied to new version. In order to get new version available for other platforms, keywording request bug should be filed.
I concur with the analysis of BDEPEND and DEPEND. Thanks for pointing that out and citing the build scripts. I guess I don't care enough about the keywording to go to the trouble of filing a whole bug for it. I can (and now do) simply blanket-accept the package on my non-amd64 machines via package.accept_keywords. I just think it'd be nice to indicate to other users that this library works on more platforms. ::shrug::
libbacktrace-1.0_p20220709-teststatic.patch (https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/libbacktrace/files/libbacktrace-1.0_p20220709-teststatic.patch?id=1defca4f16f7668b5c389c8f9760355aa932778e) causes that tests are statically linked. So static libraries from app-arch/xz-utils and sys-libs/zlib are needed, and dependencies should be: BDEPEND=" test? ( app-arch/xz-utils ) " DEPEND=" test? ( app-arch/xz-utils[static-libs] sys-libs/zlib[static-libs] ) "
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #5) > So static libraries from app-arch/xz-utils and sys-libs/zlib are needed Hmm, I don't agree with that. I have app-arch/xz-utils[-static-libs] and sys-libs/zlib[-static-libs] on my system, yet sys-libs/libbacktrace tests run successfully. I think where you're confused is that the '-static' flag to libtool links only the library/-ies *being built in the same project* statically. In order to get a fully static link, you'd have to pass '-all-static' to libtool.
(In reply to Matt Whitlock from comment #6) Does that maybe also mean that this ebuild fails in this configuration?: FEATURES="test" USE="-static-libs test" (Filing keywording bugs is trivial. Bug #875803.)
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #7) > Does that maybe also mean that this ebuild fails in this configuration?: > FEATURES="test" USE="-static-libs test" No, that's the configuration I use. It works. The build system is smart enough to additionally build the static library when you ask it to link the test programs statically, even if you configured with --disable-static. In that case, the static library is built (so that the test programs can be linked with it) but is not installed. Btw, I don't think you need to explicitly set USE="test". Setting FEATURES="test" forces it on.
Note: There is a better solution than linking the unit tests statically, proposed in this upstream PR: https://github.com/ianlancetaylor/libbacktrace/pull/99 I tested this on my Gentoo system (replacing "${FILESDIR}/libbacktrace-1.0_p20220709-teststatic.patch"), and I can confirm that it works. Note that the upstream PR does not quite apply cleanly to p20220709 because new unit tests have been introduced since then, but the non-applicable patch hunks can simply be discarded.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c99e8159e6cb8705227aab759359c158f52b64bd commit c99e8159e6cb8705227aab759359c158f52b64bd Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2023-05-28 20:52:24 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2023-05-28 20:52:24 +0000 package.mask: Mask libbacktrace for removal Bug: https://bugs.gentoo.org/880573 Bug: https://bugs.gentoo.org/864157 Bug: https://bugs.gentoo.org/885471 Bug: https://bugs.gentoo.org/870454 Bug: https://bugs.gentoo.org/884571 Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
Resurrected (and bumped) in the bitcoin-gentoo repository, as we have net-p2p/core-lightning still depending on sys-libs/libbacktrace. https://gitlab.com/bitcoin/gentoo/-/tree/master/sys-libs/libbacktrace
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d522b91a537fe515e82c67d214a5b60561c61415 commit d522b91a537fe515e82c67d214a5b60561c61415 Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2023-07-08 17:17:00 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2023-07-08 17:39:46 +0000 sys-libs/libbacktrace: treeclean Closes: https://bugs.gentoo.org/870454 Closes: https://bugs.gentoo.org/884571 Closes: https://bugs.gentoo.org/880573 Closes: https://bugs.gentoo.org/885471 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> profiles/package.mask | 5 - sys-libs/libbacktrace/Manifest | 1 - .../libbacktrace-1.0_p20220709-teststatic.patch | 287 --------------------- .../libbacktrace/libbacktrace-1.0_p20220709.ebuild | 45 ---- sys-libs/libbacktrace/metadata.xml | 11 - 5 files changed, 349 deletions(-)
