freenode/#lisp - IRC Chatlog
Search
7:42:34
White_Flame
so when using ql libs that pull in .so/.dynlib, are there tools or best practices on how to get an actual executable that doesn't die on startup on another machine without a bunch of stuff natively installed?
8:01:36
moon-child
White_Flame: bundle all the libs you need. You should be able to use strace (or similar) to see everything that gets loaded
8:03:12
White_Flame
as I've not done this before, is it common across OSes to search for dynamic libraries in the executable's directory?
8:07:36
moon-child
also if you put the libs in a separate dir from the executable (which is imo cleaner), the variable to set on windows is PATH
15:29:20
Josh_2
Whats the go to way to update already dumped lisp images? Do you normally just tell users there is a new version and get them to swap them out? Surely they could just update their running image?
15:32:38
Josh_2
I dont want to tell a user that they have to keep changing out their lisp image, I'd rather they just ran a script and it updated itself while running, I'm sure someone has done this before
15:36:02
etimmons
Josh_2: I don't know of any way to switch images while running. But if you distributed fasls you could load those into a running image to "patch" it.
15:36:39
Josh_2
sorry I wasn't clear enough, I don't mean swap images, thats equivalent to just getting and starting a new binary
15:37:37
Nilby
Updating from code is fairly easy, but can have problems. Most Lisp's can't update the image and keep running said code.
15:38:49
etimmons
White_Flame: If you're going to distribute a MacOS binary that depends on libssl, I'd recommend using the OS provided libs instead of the ones from Homebrew.
15:38:55
phoe
you could also architect your image in a way that allows it to check for updates before running everything
15:39:30
etimmons
White_Flame: IIRC, Homebrew's openssl doesn't integrate with the system keychain to get certificates and such.
15:39:59
phoe
etimmons: AFAIK libcrypto.dylib fails on modern macos/apple silicon because it has an unversioned API and Apple decided to make this a breaking change
15:40:00
Josh_2
phoe: that could work because the program is user facing and could just receive a command to update which would stop and restart it
15:40:08
Nilby
I would just reload with asdf, and the next time it got a request it would run the new code.
15:41:10
Josh_2
I also want to be able to hotload code straight into my running image, so that modules can be added/removed from my project as the user chooses
15:41:55
etimmons
phoe: There's a patch to fix it in https://github.com/cl-plus-ssl/cl-plus-ssl/pull/115. You can also work around it until the PR is merged by loading the versioned dylib yourself and pushing :cl+ssl-foreign-libs-already-loaded to *features*
15:41:58
Josh_2
Okay cool beans. I've know very little about fasls files, I guess It's time to change that
15:43:18
etimmons
White_Flame: your pastebin has /usr/local/opt/openssl/lib/libcrypto.dylib as the path it's trying to load. I think that's the Homebrew path
15:44:18
White_Flame
hmm, so at startup sbcl doesn't search the library path for dylibs, but rather just hits the exact same path that was used when the image was saved?
15:44:36
etimmons
Nothing wrong with that per se, but if you're going to share it with people that don't have Homebrew installed, I think they'll have a not-so-great time when that lib looks for trusted certs where Homebrew installs them
15:46:12
etimmons
So if you load the foreign lib "libssl.so" then it'll search again on startup. But if you give an absolute path, it'll try using that path exactly
15:46:40
White_Flame
so whatever cl+ssl or whichever dependency is loading that determines how the load happens
15:47:26
etimmons
cl+ssl uses many hardcoded paths on Darwin: https://github.com/cl-plus-ssl/cl-plus-ssl/blob/master/src/reload.lisp#L44
15:49:56
etimmons
If you want more control over which is used, look at my message to phoe about loading the dylib manually
15:58:38
etimmons
No worries! libssl is always a bit of a difficult library due to potential integration with OS keychains and such
15:59:11
etimmons
Another solution for other libraries is to statically link them into the runtime (assuming you have static libraries and the license allows such a thing)
16:00:31
etimmons
I do that quite frequently with SBCL on Linux. I assume it's not much more challenging on MacOS
16:01:03
White_Flame
however, as you bring up the user's keychain issue, that certainly is intimately tied to what's going on in the deployed OS, and not just carried-along algos
16:04:01
White_Flame
hmm, as this is basically a localhost-only application, I probably should be looking to see if clack et al can be built without https dependencies instead
16:05:54
etimmons
Are you using Hunchentoot as the underlying webserver? If so, push :hunchentoot-no-ssl to features before loading it.
17:05:40
Xach
fun fact: i have had some weird errors when doing that, and the root cause was that different *features* contexts still used the same cached fasl
17:23:14
White_Flame
Xach: a make.sh that does rm -rf ~/.cache/common-lisp covers a great many compile-time sins :-P
17:31:55
White_Flame
well, that is the definition. It's sort of like C where anything non-zero is true, and zero is false (might not be correct to the C standard, but that's what's functionally done)
17:40:24
White_Flame
afair, readline isn't used at the plain terminal due to licensing incompatibilities