In src/maxima.system, the user's $LDFLAGS get passed to ECL:
#+ecl
(defun build-maxima-lib ()
...
#-msvc
(let ((obj (mapcar #'(lambda (p)
;; Convert dir/foo.fas to dir/foo.o
(make-pathname :type "o" :defaults p))
files)))
(c::build-program "binary-ecl/maxima" :lisp-files obj
:ld-flags
(let ((x (symbol-value (find-symbol "*AUTOCONF-LD-FLAGS*"
(find-package "MAXIMA")))))
(if (and x (not (string= x ""))) (list x)))
:epilogue-code '(progn (cl-user::run)))))))
That symbol is defined to be a string in src/autoconf-variables.lisp.in:
(defparameter *autoconf-ld-flags* "@LDFLAGS@")
However, ECL is expecting a list of individual flags, not a singleton list whose sole element contains all of the flags. This leads to problems when more than one flag is present in LDFLAGS, e.g.
/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: -O1 -Wl: invalid option value (expected an integer): 1 -Wl
In short, gcc is getting called like gcc "flag1 flag2" and it doesn't like that. This can probably be fixed by splitting LDFLAGS on spaces.
Note however that not all LDFLAGS wind up in the right place at the moment: https://gitlab.com/embeddable-common-lisp/ecl/-/issues/636
The ECL issue was just fixed, so when the next ECL release is made, maxima should be able to reorganize things properly.
The new version of ECL was just released: https://ecl.common-lisp.dev/posts/ECL-2399-release.html
And the flags reorganization is part of it:
Migrating to the new names would of course be a good time to fix the original issue.
This makes sense to me, but I don't know if we can enforce using only the latest version of ecl. We'l l have to support both the new way and the old way for a while.