Hey, this is just an odd thing I noticed when packing one of my programs with qsave_program
The resulting file does what it is instructed to do, but when I do strip a.out then suddenly the program goes into the toplevel instead of executing the goal specified. Is this intentional?
Nothing like a late reply, but I just hit the exact same issue.
What appears to be going on is that qsave_program/2 produces a self-extracting Zip archive. You can run unzip -l a.out to see the embedded files.
The problem is that self-extracting Zips are essentially just executables with some compressed data concatenated at the end, and strip blindly removes any blobs not referenced by an ELF header, meaning that our quick load state gets stripped out.
That said, running file a.out does show that debug symbols are already stripped, so the right move here is to simply not run strip at all.
I agree, however, that this is a potential footgun. In my case, it was a distro package build process that automatically ran strip, causing manual builds to work, but packaged builds to, very confusingly, fail.
Actually, here’s one idea for a fix:
$ unzip a.out; zip -Dr '$prolog' a.zip # Extract the zip archive
$ strip a.out; mv a.out a.stub # Extract the ELF stub
$ objcopy --add-section .zipdata=a.zip --set-section-flags .zipdata=readonly,data a.stub plwm
Effectively, we just add a .zipdata section that points to the archive data to make sure it survives a roundtrip through binutils (e.g. strip, objcopy, etc.)
Of course, if this should be fixed at all, we’d want to do it in qsave_program/2. I’ve verified that the above process works as intended, so the idea is likely sound.
1 Like
Thanks for the update. You can also omit the standalone option in qsave_program/2, which will simply emit the zip file. Then strip swipl and use objcopy to add the zip file to it.
We could consider to automate this for ELF binaries (which we already detect as their dynamic load semantics is different from (X)COFF) and follow this procedure in case objcopy is available.
1 Like
Thanks for the reply and suggestion. I went ahead and created an issue in the tracker: GitHub · Where software is built.