I have a libbacktrace package in my overlay for use by an unrelated program, and it is causing boost to fail to install because it tries to automagically use it. But in trying to do so, it attempts to embed the static library (built without -fPIC) in a shared library. Is it a bug that it does not ignore the unsupported/undepended-on libbacktrace on the system?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2ee11719e251c9ae1a53cdcacc96ac94d7733862 commit 2ee11719e251c9ae1a53cdcacc96ac94d7733862 Author: David Seifert <soap@gentoo.org> AuthorDate: 2019-04-21 14:23:16 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2019-04-21 14:23:45 +0000 dev-libs/boost: [QA] Avoid automagic dep on libbacktrace Closes: https://bugs.gentoo.org/650478 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: David Seifert <soap@gentoo.org> dev-libs/boost/boost-1.70.0.ebuild | 1 + 1 file changed, 1 insertion(+)
Hello, I'm not quite sure that the fix here is appropriate. In my case, I want to use the boost stacktrace feature, however --without--stacktrace disables it unconditionally. As libbacktrace apparently isn't part of the portage tree, does it make sense to disable a feature because someone has libbacktrace in an overlay? I would rather suggest that the person with the libbacktrace overlay should then also provide boost ebuilds in the overlay that use --without--stacktrace, not force this on the global portage tree. Maybe I misunderstand and if I do, please correct me, but as of now, the only way for me to enable --without--stacktrace is to create a copy of the ebuild in a local overlay and I'm not sure that this is very gentoo-ish.
