Thanks for the patch. I have put it in place as https://gitlab.common-lisp.net/asdf/asdf/-/merge_requests/155
I need to have a look at the tests, and see if there's a place I can look to see if the executable flag is being set correctly, and if UIOP has the necessary features for me to be able to ask the filesystem about that.
Pierre, please grab this branch, install it, and see if it does the right thing in terms of the executable bit in both standalone executables, and images that are not standalone.
On 1 Dec 2020, at 3:56, Pierre Neidhardt wrote:
Hi!
I noticed a possible mistake in the dump-image code for CLISP:
--8<---------------cut here---------------start------------->8--- (apply #'ext:saveinitmem filename :quiet t :start-package *package* :keep-global-handlers nil :executable (if executable 0 t) ;--- requires clisp 2.48 or later, still catches --clisp-x (when executable (list ;; :parse-options nil ;--- requires a non-standard patch to clisp. :norc t :script nil :init-function #'restore-image))) --8<---------------cut here---------------end--------------->8---
According to the documentation (https://clisp.sourceforge.io/impnotes/image.html):
When non-NIL, the saved file will be a standalone executable. In this case, the #P".mem" extension is not added. On Win32 and Cygwin the extension #P".exe" is added instead. Additionally, if this argument is 0, the standard CLISP command line options will not be processed by the executable but will be placed into EXT:*ARGS* instead.
Here since we are setting `:executable` to 0 or t, the result is always executable. I don't think this is right because then the result cannot be loaded with `clisp -M path/ro/result`.
I believe the fix would be
- :executable (if executable 0 t) + :executable (if executable 0 nil)Cheers!
-- Pierre Neidhardt https://ambrevar.xyz/