portacle
portacle copied to clipboard
portacle
sbcl does not work on linux system without libz.so.1
Perhaps this is intended? But I notice it ships with a libz.so.1, so maybe not?
it's pretty easy to set an RPATH that will load this as modern linux dynamic loaders can deal with relative paths.
How are you launching sbcl? The portacle launcher should already take care of configuring the LD_LIBRARY_PATH to resolve libz apropriately.
I saw the issue originally with SLIME, and diagnosed by running lin/bin/sbcl with a working directory of the portacle root. I originally diagnosed this on NixOS, but it can be reproduced on Ubuntu 18 by moving /lib/x86_64-linux-gnu/libz.so.1.2.11, so I suspect it is not specific to NixOS.
Weird. SBCL links libz statically during compilation as it's required for core compression. This means that it should not have a runtime dependency.
@jasom are you able to provide me with a list of all shared objects that the Portacle's SBCL binary depends on? You can use ldd - and I don't expect to see libz in there.
Wait. Doesn't it? I was absolutely convinced that it did.
...I double-checked, and yes, it does not.
Well, in that case, it seems that portacle needs to ship libz.
Nevertheless if you remove the system libz, sbcl fails to launch in portacle.
Same here on both NixOS 19.09 and unstable. Most of the libs don't seem to be statically linked, and the launcher doesn't seem to setup the path (LD_LIBRARY_PATH) to use an included one:
$ ldd ./lin/sbcl/bin/sbcl
linux-vdso.so.1 (0x00007ffed89fb000)
libdl.so.2 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libdl.so.2 (0x00007f3cf4
608000)
libpthread.so.0 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libpthread.so.0 (0x
00007f3cf45e0000)
libz.so.1 => not found
libm.so.6 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libm.so.6 (0x00007f3cf444
8000)
libc.so.6 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib/libc.so.6 (0x00007f3cf429
0000)
/lib64/ld-linux-x86-64.so.2 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib64/ld-li
nux-x86-64.so.2 (0x00007f3cf4610000)
Neat that portacle itself is statically linked! It did start an emacs session for me. However, note that sbcl is not statically linked. So, porticle starts but fails to start sbcl on NixOS/anywhere that doesn't have a libz readily setup--so probably not perfect for bootstrapping. I'd probably compile sbcl statically (if possible--emacs couldn't have been easy, so maybe sbcl can be done, too) and/or setup the paths in either or both the porticle launchers and the emacs configs. Neither seem to have a path to libs for sbcl setup right now!
Only the launcher is statically linked, everything else is done via dynamic linker hacks. Figuring out how to get the stack statically linked is close to impossible. I can't use LD_LIBRARY_PATH because that would poison subprocesses (and sometimes mysteriously doesn't work as expected) and I couldn't use my usual linker hacks with SBCL for whatever reason as it just refused to launch. Maybe the situation has changed there but I kind of doubt it.
When I set my LD_LIBRARY_PATH from my environment to your lin/lib, everything seems to resolve:
[jwatt@wisdom-like-silence:/run/media/jwatt/sto/portable/portacle]$ LD_LIBRARY_PATH=$(realpath ./lin/lib) ldd lin/sbcl/bin/sbcl
linux-vdso.so.1 (0x00007ffcd67bb000)
libdl.so.2 => /run/media/jwatt/sto/portable/portacle/lin/lib/libdl.so.2 (0x00007fe56a9f0000)
libpthread.so.0 => /run/media/jwatt/sto/portable/portacle/lin/lib/libpthread.so.0 (0x00007fe56a7d
0000)
libz.so.1 => /run/media/jwatt/sto/portable/portacle/lin/lib/libz.so.1 (0x00007fe56a5b0000)
libm.so.6 => /run/media/jwatt/sto/portable/portacle/lin/lib/libm.so.6 (0x00007fe56a2a8000)
libc.so.6 => /run/media/jwatt/sto/portable/portacle/lin/lib/libc.so.6 (0x00007fe569ed8000)
/lib64/ld-linux-x86-64.so.2 => /nix/store/wx1vk75bpdr65g6xwxbj4rw0pk04v5j3-glibc-2.27/lib64/ld-li
nux-x86-64.so.2 (0x00007fe56abf8000)
Not sure how much that helps based on your last comment. Sorry. This is a neat project, though. I am mostly all "evil" and/or spacemacs these days, but I really like the idea of this project for so many reasons! Besides this issue, which I feel like is resolvable, do you think your users would be interested in "vi/vim" keybindings as an option?
I'll look closer into the build tomorrow. There might be some stuff we can do w/o relying heavily on LD_LIBRARY_PATH. I see what you mean. It's letting me down as I try to use it to launch sbcl.
I got it to work on Nix. Had to patch the sbcl binary with patchelf. This could possibly be made to work on other platforms, too. There's an automated way to do that, and I'll post/link to a default.nix package or shell.nix script in this thread later. I know it's a little redundant to use portacle on Nix in the first place because Nix kind of tries to take care of things being portable and rebuildable, but portacle looked neat to me, and I wanted to try it out. Otherr Nix users might want to try it out, too. I don't know if I'd go as far as to include it as a package in the nixpkgs repo, but I'll post a gist of the package and/or send a PR to add it to portacle if you'd like. For other platforms, we could probably use patchelf to patch the sbcl binary to point at the bundled one.
Running patchelf as part of the build would be fine by me. Thanks for looking into this!