Summary: | dev-lisp/cmucl-20b_p001 is not compatible with amd64 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | brianmlyles |
Component: | [OLD] Development | Assignee: | Andrey Grozin <grozin> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | common-lisp, jarausch, sam, sdhill, sstev3n |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log
emerge --info =dev-lisp/cmucl-20b_p001 emerge -pqv =dev-lisp/cmucl-20b_p001 |
Description
brianmlyles
2011-09-10 06:39:20 UTC
Created attachment 286033 [details]
build log
Created attachment 286035 [details]
emerge --info =dev-lisp/cmucl-20b_p001
Created attachment 286037 [details]
emerge -pqv =dev-lisp/cmucl-20b_p001
I cannot reproduce this (on x86). The file /var/tmp/portage/dev-lisp/cmucl-20b_p001/image/usr/lib/cmucl/site-init.lisp looks OK; it contains the line Read the documentation in /usr/share/doc/cmucl-20b_p001. which was produced by this sed script. The error you see must be amd64-specific. There "${D}"/usr/$(get_libdir)/cmucl/site-init.lisp must be /var/tmp/portage/dev-lisp/cmucl-20b_p001/image/usr/lib64/cmucl/site-init.lisp I suppose. Please check if you have such a file. But, unfortunately, I cannot check this myself, because I have no amd64 hardware. I do not in fact have the file /var/tmp/portage/dev-lisp/cmucl-20b_p001/image/usr/lib64/cmucl/site-init.lisp $ ls /var/tmp/portage/dev-lisp/cmucl-20b_p001/image/usr/lib/cmucl/ internals.h internals.inc lib lisp.map lisp.nm sample-wrapper (There is only lib, not lib64). Also, $ find /var/tmp/portage/dev-lisp/cmucl-20b_p001/ -iname 'site-init.lisp' yields no results. Are there any other files from /var/tmp/portage/dev-lisp/cmucl-20b_p001 that could be useful? I can upload whichever you need to see. Thanks I can confirm this bug. The issue is that there is only an x86 ebuild and no amd64 ebuild. So using $(get_libdir) is what causes this problem. On amd64 it will return lib64, but there is no lib64 directory created within the build, so the site-init.lisp file cannot be created. I simply changed "$(get_libdir)" to "lib" in the ebuild to work around this problem. *** Bug 545084 has been marked as a duplicate of this bug. *** *** Bug 547046 has been marked as a duplicate of this bug. *** @grozin do we (common-lisp) have something to do here? I was able to build cmucl-21c on amd64 using the upstream -O1 patch https://gitlab.common-lisp.net/cmucl/cmucl/merge_requests/45, but it still fails in src_install due to the get_libdir thing. Nonetheless, the current ebuild has no amd64 keywords. I could take a look and fix the ebuild in the lisp overlay if you care. Thanks The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=619a139a19f2b798c3088d28d6956790d2e96ea8 commit 619a139a19f2b798c3088d28d6956790d2e96ea8 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-01-19 01:13:14 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-01-19 01:13:19 +0000 dev-lisp/cmucl: add -* to KEYWORDS (needs binary to bootstrap) Closes: https://bugs.gentoo.org/831436 Bug: https://bugs.gentoo.org/382463 Signed-off-by: Sam James <sam@gentoo.org> dev-lisp/cmucl/cmucl-21c.ebuild | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (In reply to Larry the Git Cow from comment #10) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=619a139a19f2b798c3088d28d6956790d2e96ea8 > > commit 619a139a19f2b798c3088d28d6956790d2e96ea8 > Author: Sam James <sam@gentoo.org> > AuthorDate: 2022-01-19 01:13:14 +0000 > Commit: Sam James <sam@gentoo.org> > CommitDate: 2022-01-19 01:13:19 +0000 > > dev-lisp/cmucl: add -* to KEYWORDS (needs binary to bootstrap) > > Closes: https://bugs.gentoo.org/831436 > Bug: https://bugs.gentoo.org/382463 > Signed-off-by: Sam James <sam@gentoo.org> > > dev-lisp/cmucl/cmucl-21c.ebuild | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Why? cmucl is a high-quality *x86-only* lisp. Porting it to amd64 is a non-trivial task because of a different number of bits in a pointer (cmucl uses some bits in pointers in funny ways), for other arches porting is, probably, impossible. It should have KEYWORDS="x86", there should be no attempts to use this ebuild on other arches, but for x86 is should work fine. I no longer have x86 systems and cannot check this now, but, when I had such a system, cmucl was one of the fastest lisps on it. Yes, it is not compatible with amd64. This is not a bug, but a feature. (In reply to Andrey Grozin from comment #11) > (In reply to Larry the Git Cow from comment #10) > > The bug has been referenced in the following commit(s): > > > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=619a139a19f2b798c3088d28d6956790d2e96ea8 > > > > commit 619a139a19f2b798c3088d28d6956790d2e96ea8 > > Author: Sam James <sam@gentoo.org> > > AuthorDate: 2022-01-19 01:13:14 +0000 > > Commit: Sam James <sam@gentoo.org> > > CommitDate: 2022-01-19 01:13:19 +0000 > > > > dev-lisp/cmucl: add -* to KEYWORDS (needs binary to bootstrap) > > > > Closes: https://bugs.gentoo.org/831436 > > Bug: https://bugs.gentoo.org/382463 > > Signed-off-by: Sam James <sam@gentoo.org> > > > > dev-lisp/cmucl/cmucl-21c.ebuild | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > Why? cmucl is a high-quality *x86-only* lisp. Porting it to amd64 is a > non-trivial task because of a different number of bits in a pointer (cmucl > uses some bits in pointers in funny ways), for other arches porting is, > probably, impossible. It should have KEYWORDS="x86", there should be no > attempts to use this ebuild on other arches, but for x86 is should work > fine. I no longer have x86 systems and cannot check this now, but, when I > had such a system, cmucl was one of the fastest lisps on it. I think you've misundestood the commit. It was marking it as -* to ensure that nobody attempts to keyword it accidentally (like what happened in bug 831436). It does _not_ prevent installing it on x86, as it has "-* .. x86". i.e. the commit just does exactly what you suggested, prevent people from trying it on other arches accidentally. (In reply to Andrey Grozin from comment #12) > Yes, it is not compatible with amd64. This is not a bug, but a feature. Not convinced it's actually a "feature", just a property and a known one, but fine. :) |