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
```diff
- :executable (if executable 0 t)
+ :executable (if executable 0 nil)
```
Cheers!
--
Pierre Neidhardt
https://ambrevar.xyz/
