|
From: Robert S. <ro...@st...> - 2026-04-30 22:32:43
|
I am very happy to work on documentation. I've also been running with this for a little bit now, making tweaks to some of the commits as users find issues. The recently announced `mine` software is being compiled with this SBCL branch to (a) allow the executable to be signed, and (b) to allow executables dumped with S-L-A-D to be runnable. (They now are on both macOS and Windows, including x64/ARM and x64-on-ARM-with-Prism.) https://coalton-lang.github.io/mine/ I'll write up some docs and ping again for discussion or review. Robert On Wednesday, April 29th, 2026 at 3:49 PM, Christophe Rhodes <cs...@ca...> wrote: > (I missed this, because some authority in the sky? cloud? decided that > your initial message was spam. Sorry about that.) > > I think that an existing use case strongly suggests that we should be > working with you to make this supported. > > I think tools-for-build/ is not an unreasonable place for > make-embedded-core-executable.lisp, given the similar nature of the > elfcore related utilities there. On the ergonomics, I think it would be > OK to initially redefine SAVE-LISP-AND-DIE to not allow executable > cores, if that's easier to get started. (I think the thing I am most > interested in to start with if you're willing to work on this is some > highish-level documentation). > > Christophe > > Robert Smith <ro...@st...> writes: > > > Two issues/gotchas with this: > > > > 1. If an executable is saved and modified in the way described, then S-L-A-D won't work with that executable on Windows. (It produces an executable, but it's invalid.) > > > > 2. If a signature is added, S-L-A-D will happily carry that signature over, and the resulting executable won't run due to an invalid signature. > > > > These are tangential to the feature of *reading* the core, but would be necessary considerations if *writing* became first-class and supported. > > > > If maintainers are interested in this feature and they want me to try my hand at building it, I can. It would convenience me, because my users will want to call S-L-A-D and have it work. :) > > > > Robert > > > > > > On Friday, April 17th, 2026 at 7:02 PM, Robert Smith <ro...@st...> wrote: > > > >> Hello SBCL friends: > >> > >> I've been building an app that I want to actually distribute to > >> real, human people on the internet for Windows, Mac, and Linux. In > >> order to make the experience seamless, the app should be > >> code-signed. As you may know, code-signing does not work > >> out-of-the-box on Windows and Mac with SBCL-produced executables, > >> because either (a) signing clobbers the executable in some way, or > >> (b) signing tools reject it as an executable with an invalid format. > >> > >> There are various workarounds with different trade-offs, but in my > >> limited experience with code signing so far, the right answer is to > >> just make executables that are of a valid structured format. It > >> seems there was some work to do this with ELF in the tree already, > >> but I'm not sure people on Linux care about code signing. (?) > >> > >> As such, please take a look at this patch: > >> > >> https://github.com/sbcl/sbcl/compare/master...stylewarning:sbcl:signable-executables > >> > >> The commit message describes everything which I won't recap here. The TL;DR for posterity: > >> > >> - It allows coreparse to understand when cores are located in an executable section on Windows and 64-bit Mac, while maintaining backward compatibility with the concatenated core. > >> > >> - It adds a utility script that allows taking a core + a runtime and creating a proper, signable executable. > >> > >> I don't really know the right place for the > >> > >> tools-for-build/make-embedded-core-executable.lisp > >> > >> file. It's not really a "tool for building". > >> > >> I originally extended S-L-A-D with additional options, but the code > >> became a bloated mess of over 1000 lines of reading environment > >> variables, parsing them, trying to find a working $CC, invoking > >> linkers from the SBCL process, etc. I decided that if we want this > >> to be "built-in" in the future, we can, but to start with the > >> minimum useful surface area first. > >> > >> I also originally added the make-embedded...lisp file to install.sh, but removed it, since it might be confusing to users since it's not in the documentation anywhere. > >> > >> Perhaps most importantly, I am actively using this branch to produce valid, code-signed artifacts for Windows and Mac that "just work". > >> > >> Please let me know if you have any comments. > >> > >> Robert > >> > >> > >> > >> _______________________________________________ > >> Sbcl-devel mailing list > >> Sbc...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbcl-devel > >> > > > > > > _______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > |