Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 504720 - dev-lang/moarvm-2022.02 lacks a SONAME
Summary: dev-lang/moarvm-2022.02 lacks a SONAME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Patrick Lauer
Depends on:
Blocks: raku
  Show dependency tree
Reported: 2014-03-15 15:32 UTC by Julian Ospald
Modified: 2022-03-04 07:30 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Julian Ospald 2014-03-15 15:32:11 UTC
* QA Notice: The following shared libraries lack a SONAME
 * /usr/lib/
Comment 1 Tanktalus 2016-05-09 04:15:12 UTC
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
 * to make sure the issue is fixed.
 *  For more information, see:
 *  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/

 * QA Notice: The following shared libraries lack a SONAME
 * /usr/lib/

making executable: usr/lib/
Files matching a file type that is not allowed:
 * ERROR: dev-lang/moarvm-2016.04::gentoo failed:
 *   multilib-strict check failed!
 * Call stack:
 *, line 603:  Called install_qa_check
 *, 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.
Comment 2 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-08-06 04:00:35 UTC
I'll just point out that as of moarvm 2019.07.1, 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 
/usr/bin/perl -MExtUtils::Command -e rm_f "/var/tmp/portage/dev-lang/moarvm-2019.07.1/imagelib64/"
/usr/bin/perl -MExtUtils::Command -e cp  "/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 :(
Comment 3 Larry the Git Cow gentoo-dev 2019-08-06 05:30:22 UTC
The bug has been referenced in the following commit(s):

commit af79c1ba88221c2e88a0881ac162a0e0599611e2
Author:     Kent Fredric <>
AuthorDate: 2019-08-06 05:22:48 +0000
Commit:     Kent Fredric <>
CommitDate: 2019-08-06 05:29:34 +0000

    dev-lang/moarvm: Fix installation to /lib re bug #639538
    This fixes the installation of 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
    Package-Manager: Portage-2.3.66, Repoman-2.3.16
    Signed-off-by: Kent Fredric <>

 ...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(-)
Comment 4 Kent Fredric (IRC: kent\n) (RETIRED) gentoo-dev 2019-08-06 05:35:44 UTC
(In reply to Kent Fredric (IRC: kent\n) from comment #2)
> I'll just point out that as of moarvm 2019.07.1, 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. 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.
Comment 5 Agostino Sarubbo gentoo-dev 2021-10-01 07:32:04 UTC
tinderbox has reproduced this issue with version 2021.08 - Updating summary.
Comment 6 Agostino Sarubbo gentoo-dev 2021-11-25 15:00:42 UTC
ci has reproduced this issue with version 2021.10 - Updating summary.
Comment 7 Agostino Sarubbo gentoo-dev 2022-03-04 07:30:41 UTC
ci has reproduced this issue with version 2022.02 - Updating summary.