on CCL `Foreign function not found: X86-LINUX64::|memset|` compiling impl-clozure.lisp
eschulte opened this issue · 13 comments
This is with the latest CCL ccl-git-4778.ea47784e running on Linux 4.17.11-arch1.
Please let me know if I can provide additional reproduction information.
Thanks,
Eric
I'm experiencing this on OSX 10.13 with ccl ccl-v1.12-dev.3-24-g1fd2a4b4.
Is this still an issue ? I cannot reproduce on Linux using v1.12-dev.5-19-gb8e8bf8763f7
I just reproduced on Arch Linux with the latest CCL built from git (using https://aur.archlinux.org/packages/ccl-git/). The version of static-vectors is static-vectors-v1.8.3 installed at some point via quicklisp.
You can reproduce with the attached Dockerfile.txt by running the following:
mkdir /tmp/empty
docker build -f Dockerfile.txt -t static-vectors-error /tmp/empty
I suspect the Arch CCL package is broken, e.g. the following is very suspicious:
==> Tidying install...
-> Removing libtool files...
-> Purging unwanted files...
-> Removing static library files...
-> Stripping unneeded symbols from binaries and libraries...
In any case, I cannot help with Arch. I suggest you try to reproduce using the official binaries instead.
Confirmed, this is not a problem with the official binaries so please feel free to close.
If you have a suggestion for how to change the ccl-git Arch package I'm happy to try it. I tried disabling all of the configurable Arch cleaning (Removing static library files, etc...) but that didn't help.
Try adding this to the build file:
options=(debug !strip)
With those options (and all of the other combinations of options I tried) this still continues to fail. I've mentioned this on the relevant Arch package page so I'm assuming it is in the package maintainers hands for now. Thanks for your help!
Also had this problem now with the AUR package.
Can you reproduce using the official binaries ?
Everything went fine with the official binaries :). I was going to update my comment when I got it running. Thanks for the obscenely quick answer!
I suggest you talk to the AUR package maintainers and have this fixed.
I have this error on my own build after dumping the image. The issue is that ccl logical pathnames translations are not correctly set when the binary is moved (similar with navigating to the source code). The missing file is x86-headers64/libc/functions.cdb -- the executable tries to look for it in the same directory the executable is located.
The issue is not present when the directory /is/ present in the same directory or when the pathname logical translations are updated. Mind that translations must be updated before the foreign function (like memset) is referenced.
For example, assuming that ccl the source code is in /home/jack/Desktop/cl-builds/ccl-1.12-2019.04-snapshot and the binary is in /home/jack/Desktop/yolo:
CL-USER> (logical-pathname-translations "ccl")
((#P"ccl:l1;**;*.*" #P"ccl:level-1;**;*.*")
(#P"ccl:l1f;**;*.*" #P"ccl:l1-fasls;**;*.*")
(#P"ccl:ccl;*.*" #P"/home/jack/Desktop/yolo/*.*")
(#P"ccl:**;*.*" #P"/home/jack/Desktop/yolo/**/*.*"))
CL-USER> (setf (logical-pathname-translations "ccl")
'((#P"ccl:l1;**;*.*" #P"ccl:level-1;**;*.*")
(#P"ccl:l1f;**;*.*" #P"ccl:l1-fasls;**;*.*")
(#P"ccl:ccl;*.*" #P"/home/jack/Desktop/cl-builds/ccl-1.12-2019.04-snapshote/*.*")
(#P"ccl:**;*.*" #P"/home/jack/Desktop/cl-builds/ccl-1.12-2019.04-snapshot/**/*.*")))
((#P"ccl:l1;**;*.*" #P"ccl:level-1;**;*.*")
(#P"ccl:l1f;**;*.*" #P"ccl:l1-fasls;**;*.*")
(#P"ccl:ccl;*.*" #P"/home/jack/Desktop/cl-builds/ccl-1.12-2019.04-snapshot/*.*")
(#P"ccl:**;*.*" #P"/home/jack/Desktop/cl-builds/ccl-1.12-2019.04-snapshot/**/*.*"))