* QA Notice: The following shared libraries lack a SONAME * /usr/lib/libmoar.so
Is there a workaround to this? I'm getting this and more: * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see: * * https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart * * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/lib/libmoar.so * QA Notice: The following shared libraries lack a SONAME * /usr/lib/libmoar.so making executable: usr/lib/libmoar.so Files matching a file type that is not allowed: usr/lib/libmoar.so * ERROR: dev-lang/moarvm-2016.04::gentoo failed: * multilib-strict check failed! * * Call stack: * misc-functions.sh, line 603: Called install_qa_check * misc-functions.sh, line 217: Called source 'install_symlink_html_docs' * 80multilib-strict, line 47: Called multilib_strict_check * 80multilib-strict, line 43: Called die * The specific snippet of code: * [[ ${abort} == yes ]] && die "multilib-strict check failed!" * * If you need support, post the output of `emerge --info '=dev-lang/moarvm-2016.04::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-lang/moarvm-2016.04::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-lang/moarvm-2016.04/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-lang/moarvm-2016.04/temp/environment'. * Working directory: '/var/tmp/portage/dev-lang/moarvm-2016.04/image' * S: '/var/tmp/portage/dev-lang/moarvm-2016.04/work/MoarVM-2016.04' !!! post install failed; exiting.
I'll just point out that as of moarvm 2019.07.1, libmoar.so is no longer installed. I'm not entirely sure why this is, or if its needed, just something to keep an eye on. Only relevant entries from the emerge log are: zgrep 'libmoar' /var/log/portage/build/dev-lang/moarvm-2019.07.1\:20190805-093630.log.gz linking libmoar.so /usr/bin/perl -MExtUtils::Command -e rm_f "/var/tmp/portage/dev-lang/moarvm-2019.07.1/imagelib64/libmoar.so" /usr/bin/perl -MExtUtils::Command -e cp libmoar.so "/var/tmp/portage/dev-lang/moarvm-2019.07.1/imagelib64" But there's a new QA notice which mentions `-lmoar`: * QA Notice: pkg-config files with wrong LDFLAGS detected: * /usr/share/pkgconfig/moar.pc:Libs: -Wl,-O1 -Wl,--as-needed -Llib64 -lmoar Which I suspect, if anything tries to actually use that package-config entry, will fail to build. I can't find an upstream change that explains this :(
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=af79c1ba88221c2e88a0881ac162a0e0599611e2 commit af79c1ba88221c2e88a0881ac162a0e0599611e2 Author: Kent Fredric <kentnl@gentoo.org> AuthorDate: 2019-08-06 05:22:48 +0000 Commit: Kent Fredric <kentnl@gentoo.org> CommitDate: 2019-08-06 05:29:34 +0000 dev-lang/moarvm: Fix installation to /lib re bug #639538 This fixes the installation of libmoar.so to use /usr/lib64 etc instead of /lib64 This additionally fixes the issue where the installation to /lib64 under EAPI7, for some reason, results in no installation of the .so, as mentioned in bug #504720 Closes: https://bugs.gentoo.org/639538 Bug: https://bugs.gentoo.org/504720 Package-Manager: Portage-2.3.66, Repoman-2.3.16 Signed-off-by: Kent Fredric <kentnl@gentoo.org> ...rvm-2018.12.ebuild => moarvm-2018.06-r1.ebuild} | 8 ++- dev-lang/moarvm/moarvm-2018.06.ebuild | 57 -------------------- ...rvm-2018.08.ebuild => moarvm-2018.08-r1.ebuild} | 10 ++-- ...rvm-2018.09.ebuild => moarvm-2018.09-r1.ebuild} | 10 ++-- dev-lang/moarvm/moarvm-2018.12-r1.ebuild | 61 ++++++++++++++++++++++ ...rvm-2019.03.ebuild => moarvm-2019.03-r1.ebuild} | 8 ++- ...rvm-2019.07.ebuild => moarvm-2019.07-r1.ebuild} | 8 ++- ...2019.07.1.ebuild => moarvm-2019.07.1-r1.ebuild} | 8 ++- dev-lang/moarvm/moarvm-9999.ebuild | 8 ++- 9 files changed, 105 insertions(+), 73 deletions(-)
(In reply to Kent Fredric (IRC: kent\n) from comment #2) > I'll just point out that as of moarvm 2019.07.1, libmoar.so is no longer > installed. > > I'm not entirely sure why this is, or if its needed, just something to keep > an eye on. Ignore my previous remarks, sleuthing found it was EAPI6 -> EAPI7 related, in conjunction with bad --libdir invocation. libmoar.so is back, and the QA waaambulance is back, but the crying about the .pc entry is gone \o/ Upstream has a ticket too, but like, not top priority atm.
tinderbox has reproduced this issue with version 2021.08 - Updating summary.
ci has reproduced this issue with version 2021.10 - Updating summary.
ci has reproduced this issue with version 2022.02 - Updating summary.
ci has reproduced this issue with version 2022.06 - Updating summary.
ci has reproduced this issue with version 2023.02 - Updating summary.
gcc14_tinderbox has reproduced this issue with version 2023.10 - Updating summary.
gcc14_tinderbox has reproduced this issue with version 2023.12 - Updating summary.
ci has reproduced this issue with version 2024.02 - Updating summary.
ci has reproduced this issue with version 2024.04 - Updating summary.
ci has reproduced this issue with version 2024.05 - Updating summary.
ci has reproduced this issue with version 2024.08 - Updating summary.
ci has reproduced this issue with version 2024.10 - Updating summary.
