| Summary: | sbcl-0.8.20 fails to merge with error about lib64 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David Leverton <levertond> |
| Component: | [OLD] Development | Assignee: | Gentoo Lisp Project <lisp> |
| Status: | VERIFIED TEST-REQUEST | ||
| Severity: | normal | CC: | dirk, gentoo |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
David Leverton
2005-04-03 16:05:25 UTC
That's odd... What does `ls -l /usr/ | grep lib` say? I get the following: # ls -l /usr/ | grep lib drwxr-xr-x 102 root root 70960 Apr 10 20:24 lib lrwxrwxrwx 1 root root 25 Mar 15 11:06 lib32 -> ../emul/linux/x86/usr/lib lrwxrwxrwx 1 root root 3 Mar 13 18:14 lib64 -> lib drwxr-xr-x 9 root root 1912 Apr 6 20:36 libexec Hmm, I looked into it further, I think the error's coming from the impl-save-timestamp-hack function in common-lisp-common-2.eclass - it does
tar cpjf ${D}/usr/share/${impl}/portage-timestamp-compensate -C ${D}/usr/$(get_libdir)/${impl} .
but /var/tmp/portage/sbcl-0.8.20/image/usr only contains bin, lib and share directories. So, sbcl's src_install would need to be changed to put things in /usr/$(get_libdir) instead of /usr/lib.
I don't get this error at all with SBCL on AMD64. Is my system unusual in that /usr/lib is a directory and /usr/lib64 a symlink to it? The error's happening while it's still inside the sandbox, in /var/tmp/portage/sbcl-0.8.20/image. Also, it's probably specific to the 2005.0 profile, IIRC that's the first one that's actually refered to lib64 during the builds. Dirk, do you have multilib in USE? I think that I will change the $(get_libdir), to simply "lib". Or the other way around. Matthew, yes I have multilib in USE, because some package (don't remember which) required GCC to be built with multilib. I asked the developer who made those changes to the eclasses which caused this breakage what "multilibs" means for us. I'll know what do once i hear back. I changed the ebuild for sbcl-0.8.21-r1 to use /usr/$(get_libdir) instead of /usr/lib. This should fix this bug, so I'll mark this resolved with a test request. That still didn't do it, but I looked in the ebuild and the install scripts in more detail - adding
sed -i "s,/lib,/$(get_libdir),g" ${S}/install.sh
to src_unpack, after extracting the tarball, seems to work, in addition to the existing changes. I haven't tested it very extensively, though.
I had the same problem, and solved it as described by David Leverton in comment #9. I haven't played around with it a tremendous amount, but I've compiled the cl-ppcre module and played with it a bit, and it appears to be working. I was trying to experiment with mcclim as a large-scale piece of software to verify things are working, but I couldn't get any examples to run. However, I think that is because I don't have any idea what I'm doing yet. *** Bug 91357 has been marked as a duplicate of this bug. *** The ebuild for sbcl-0.9.1 just committed to portage applies the fix to install.sh. Thanks for noting this problem. I'll resolve this with a test request. sbcl-0.9.1 works for me now. Thanks. Works for me also. Thanks! thanks for the testing. |
