The important bit from the build log: + echo '(lisp-implementation-type)' + sh /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/src/runtime/sbcl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/src/runtime/sbcl) + echo 'No working host Common Lisp implementation.' No working host Common Lisp implementation. I have the same failure for all sbcl-2.2.[0|2|3]. I'm not quite sure why the host libc seems to enter the picture.
Created attachment 769949 [details] build.log for sbcl-2.2.0
I tried the retired sbcl-2.1.11 with the same result + sh /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.1.11/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.1.11/work/sbcl-binary/src/runtime/sbcl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.1.11/work/sbcl-binary/src/runtime/sbcl) + echo 'No working host Common Lisp implementation.' No working host Common Lisp implementation. So maybe something is wrong with my Prefix which was just recently installed.
It looks like your host glibc is probed instead of your prefix one. This is tricky, the ebuild should pre-load the prefix glibc before running the binary sbcl.
A data point: set the location of libc.so.6: $ export LD_LIBRARY_PATH=/storage/strogdon/gentoo-rap/lib64 run the script: $ sh /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/src/runtime/sbcl: relocation error: /storage/strogdon/gentoo-rap/lib64/libc.so.6: symbol _dl_catch_error_ptr, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference So now the correct libc is found but no joy! Using sys-libs/glibc-2.33-r13
I think this may have the same root cause as bug 712626. Can you try it?
Making the minimal changes: --- /storage/strogdon/gentoo-rap/usr/portage/dev-lisp/sbcl/sbcl-2.2.0.ebuild 2022-02-17 04:39:54.000000000 -0700 +++ /storage/strogdon/gentoo-rap/usr/local/portage/dev-lisp/sbcl/sbcl-2.2.0.ebuild 2022-04-11 23:49:10.791876759 -0600 @@ -156,13 +156,16 @@ src_compile() { local bindir="${WORKDIR}"/sbcl-binary + # Use ecl to bootstrap + local bootstrap_sbcl="ecl" + # clear the environment to get rid of non-ASCII strings, see bug #174702 # set HOME for paludis env - HOME="${T}" PATH="${PATH}" \ CC="$(tc-getCC)" AS="$(tc-getAS)" LD="$(tc-getLD)" \ CPPFLAGS="${CPPFLAGS}" CFLAGS="${CFLAGS}" ASFLAGS="${ASFLAGS}" LDFLAGS="${LDFLAGS}" \ GNUMAKE=make ./make.sh \ - "sh ${bindir}/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger" \ + "${bootstrap_sbcl}" \ || die "make failed" # need to set HOME because libpango(used by graphviz) complains about it I do get a bit further, but eventually the compile phase fails + echo //building runtime system and symbol table file //building runtime system and symbol table file + make -C src/runtime clean make: Entering directory '/storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-2.2.0/src/runtime' GNUmakefile:41: genesis/Makefile.features: No such file or directory make: *** No rule to make target 'genesis/Makefile.features'. Stop. make: Leaving directory '/storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-2.2.0/src/runtime' Command exited with non-zero status 2
That wouldn't happen if the sbcl binary was statically linked. Let's get the heavy artillery, instead of using LD_LIBRARY_PATH let's move to using LD_PRELOAD. In your case LD_PRELOAD=/storage/strogdon/gentoo-rap/lib64/ld-linux-x86-64.so.2:/storage/strogdon/gentoo-rap/lib64/libc.so.6 And progressively add the other needed libraries if it is not enough. $ readelf -d src/runtime/sbcl Dynamic section at offset 0x53d88 contains 29 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
(In reply to François Bissey from comment #7) > That wouldn't happen if the sbcl binary was statically linked. Let's get the > heavy artillery, instead of using LD_LIBRARY_PATH let's move to using > LD_PRELOAD. In your case > > LD_PRELOAD=/storage/strogdon/gentoo-rap/lib64/ld-linux-x86-64.so.2:/storage/ > strogdon/gentoo-rap/lib64/libc.so.6 > > And progressively add the other needed libraries if it is not enough. > $ readelf -d src/runtime/sbcl > > Dynamic section at offset 0x53d88 contains 29 entries: > Tag Type Name/Value > 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] > 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] > 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] > 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] If I preload ld-linux-x86-64.s0.2 I get a segfault $ export LD_PRELOAD=/storage/strogdon/gentoo-rap/lib64/ld-linux-x86-64.so.2:/storage/strogdon/gentoo-rap/lib64/libc.so.6 $ ./run-sbcl.sh Segmentation fault (core dumped) preloading just libc.so.6 gives the original "version `GLIBC_2.28' not found"
OK, let's do this correctly. I forgot the sh, but still a segfault: $ export LD_PRELOAD=/storage/strogdon/gentoo-rap/lib64/ld-linux-x86-64.so.2:/storage/strogdon/gentoo-rap/lib64/libc.so.6:/storage/strogdon/gentoo-rap/lib64/libm.so.6:/storage/strogdon/gentoo-rap/lib64/libpthread.so.0 $ sh /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.0/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger This is SBCL 2.2.0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Segmentation fault (core dumped)
I am wondering if all the workaround I am thinking of should in fact be inserted in the shell script before the call to sbcl rather than outside of it, which may cause problems. May be we should make sure the script call shell from the prefix rather than the host one? I have a feeling that's what's happening now.
(In reply to François Bissey from comment #10) > I am wondering if all the workaround I am thinking of should in fact be > inserted in the shell script before the call to sbcl rather than outside of > it, which may cause problems. > > May be we should make sure the script call shell from the prefix rather than > the host one? I have a feeling that's what's happening now. I tried a variety of things along this line, even making sure the sh was the correct one with no success. Now readelf -l sbcl Elf file type is DYN (Position-Independent Executable file) Entry point 0x10910 There are 12 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x00000000000002a0 0x00000000000002a0 R 0x8 INTERP 0x00000000000002e0 0x00000000000002e0 0x00000000000002e0 0x000000000000001c 0x000000000000001c R 0x1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000000f5a0 0x000000000000f5a0 R 0x1000 LOAD 0x0000000000010000 0x0000000000010000 0x0000000000010000 0x0000000000031dc9 0x0000000000031dc9 R E 0x1000 LOAD 0x0000000000042000 0x0000000000042000 0x0000000000042000 0x000000000000d0f0 0x000000000000d0f0 R 0x1000 LOAD 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000002918 0x000000000000a578 RW 0x1000 DYNAMIC 0x000000000004fd88 0x0000000000050d88 0x0000000000050d88 0x0000000000000210 0x0000000000000210 RW 0x8 NOTE 0x00000000000002fc 0x00000000000002fc 0x00000000000002fc 0x0000000000000044 0x0000000000000044 R 0x4 TLS 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000000000 0x0000000000000008 R 0x8 GNU_EH_FRAME 0x0000000000048c84 0x0000000000048c84 0x0000000000048c84 0x0000000000001244 0x0000000000001244 R 0x4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 GNU_RELRO 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000000e70 0x0000000000000e70 R 0x1 So does this suggest that the path to ld-linux-x86-64.so.2 is hard-coded? On the host ls -al /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 32 Mar 27 2019 /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.19.so
Someone with more elf foo would need to answer that hardcoding question. My own opinion is "no". But that's merely an opinion, I don't have hard facts on the matter.
Changing the interpreter works. ebuild sbcl-2.2.0.ebuild configure patchelf --set-interpreter ${EPREFIX}/lib64/ld-linux-x86-64.so.2 sbcl ebuild sbcl-2.2.0.ebuild compile builds sbcl readelf -l sbcl Elf file type is DYN (Position-Independent Executable file) Entry point 0x10910 There are 14 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040 0x0000000000000310 0x0000000000000310 R 0x8 LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x000000000000f5a0 0x000000000000f5a0 R 0x1000 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0x10 LOAD 0x0000000000010000 0x0000000000010000 0x0000000000010000 0x0000000000031dc9 0x0000000000031dc9 R E 0x1000 LOAD 0x0000000000042000 0x0000000000042000 0x0000000000042000 0x000000000000d0f0 0x000000000000d0f0 R 0x1000 GNU_EH_FRAME 0x0000000000048c84 0x0000000000048c84 0x0000000000048c84 0x0000000000001244 0x0000000000001244 R 0x4 LOAD 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000002918 0x000000000000a578 RW 0x1000 TLS 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000000000 0x0000000000000008 R 0x8 GNU_RELRO 0x000000000004f190 0x0000000000050190 0x0000000000050190 0x0000000000000e70 0x0000000000000e70 R 0x1 DYNAMIC 0x000000000004fd88 0x0000000000050d88 0x0000000000050d88 0x0000000000000210 0x0000000000000210 RW 0x8 LOAD 0x00000000001f8000 0x00000000001f8000 0x00000000001f8000 0x0000000000001370 0x0000000000001370 RW 0x1000 INTERP 0x00000000001f92f0 0x00000000001f92f0 0x00000000001f92f0 0x0000000000000038 0x0000000000000038 R 0x1 [Requesting program interpreter: /storage/strogdon/gentoo-rap/lib64/ld-linux-x86-64.so.2] NOTE 0x00000000001f9328 0x00000000001f9328 0x00000000001f9328 0x0000000000000020 0x0000000000000020 R 0x4 NOTE 0x00000000001f9348 0x00000000001f9348 0x00000000001f9348 0x0000000000000024 0x0000000000000024 R 0x4
I have officially learnt new stuff here. That trick is still probably dependent on available padding in the executable but there is not much you can do about that.
Well, even though sbcl built and installed, there is still an issue $ sbcl fatal error encountered in SBCL pid 27953 tid 27953: Can't find sbcl.core Bummer! sbcl.core exists under the work folder but did not get installed, so maybe just and ebuild install issue.
Not an ebuild issue, probably a build path issue. sblc.core is installed correctly under ${EPREFIX}/usr/lib64/sbcl.
The executable sbcl incorrectly looks under ${EPREFIX/usr/lib/sbcl for sbcl.core. Manually creating a symlink from ${EPREFIX/usr/lib/sbcl -> ${EPREFIX/usr/lib64/sbcl, sbcl now works. $ sbcl This is SBCL 2.2.0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. *
Can you check `SBCL_HOME` in `etc/env.d/50-sbcl`? Also, does your prefix comes with `lib` or `lib64` as default?
(In reply to François Bissey from comment #18) > Can you check `SBCL_HOME` in `etc/env.d/50-sbcl`? Also, does your prefix > comes with `lib` or `lib64` as default? SBCL_HOME is OK $ cat ~/etc/env.d/50sbcl SBCL_HOME=/storage/strogdon/gentoo-rap/usr/lib64/sbcl SBCL_SOURCE_ROOT=/storage/strogdon/gentoo-rap/usr/lib64/sbcl/src My prefix comes with both lib and lib64. They are not symlinks, just like on Gentoo. When I did an strace of running sbcl it only looked in ${EPREFIX}/usr/lib/sbcl and did not try ${EPREFIX/usr/lib64/sbcl. This I find strange since the Gentoo build behaves properly.
Everything OK. Logged out of the prefix and then back in and sbcl works as it should. Apparently the env had to be updated.
Created attachment 771974 [details, diff] rough ebuild patch
FWIW this sounds like the correct thing to do. The interpreter version should be retrieved from the active system, and only set for RAP.
This issue still exists with sbcl-2.2.9 + echo '(lisp-implementation-type)' + sh /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.9/work/sbcl-binary/run-sbcl.sh --no-sysinit --no-userinit --disable-debugger /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.9/work/sbcl-binary/src/runtime/sbcl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /storage/strogdon/gentoo-rap/var/tmp/portage/dev-lisp/sbcl-2.2.9/work/sbcl-binary/src/runtime/sbcl) + echo 'No working host Common Lisp implementation.' No working host Common Lisp implementation.
Please check is sbcl-2.2.11 with the fix proposed here included works for you. I don't run prefix systems, and cannot check this myself.
(In reply to Andrey Grozin from comment #24) > Please check is sbcl-2.2.11 with the fix proposed here included works for > you. I don't run prefix systems, and cannot check this myself. sbcl-2.2.11 does build here on my prefix system.
(In reply to Steven Trogdon from comment #25) > sbcl-2.2.11 does build here on my prefix system. Thanks
