[Ecls-list] Building native EXE on Windows is too hard!
Juan Jose Garcia-Ripoll
juanjose.garciaripoll at gmail.com
Fri Nov 9 20:40:29 UTC 2012
On Thu, Nov 8, 2012 at 9:04 AM, Ralph Möritz <ralph.moeritz at outlook.com>wrote:
> Re. #2, I don't really mind what ECL does with large constant strings
> behind the
> scenes, the point is that ECL *knows* which compiler it's using so it
> *could* do whatever is necessary such as setting *COMPILE-IN-CONSTANTS* or
> passing the appropriate compiler switches to find the ECL libs. If Franjo &
> the regulars don't have time to implement this, I'll be happy to do it
> myself & post a patch - Just let me know where in the source to start
> looking.
>
Sorry, my name is Juanjo, not Franjo :-) Regarding compile-in-constants, I
think you guys do not know the real history. Microsoft's compiler has a
severe limitation in compiler string size. This means we cannot build
constant data that takes more than 64k. The only way we escape this in FASL
files is by appending the data to the compiled file. This *does not
work*with standalone executables for various reasons: we cannot append
the data
to the object files (the linker complains); even if this was solved, we
cannot append it to the executable, because there is no way to locate it
(other than searching through the path, but not even that, always).
So when you use (setq *compile-in-constants* t) you are implicitely
accepting the following contract: my compiler is crap and I will not
complain if it fails to build the library I want to use.
Since most users are using ECL for loading libraries, not building
standalone files, right now we set *compile-in-constants* to NIL. We have
to do so because there are libraries out there that generate a lot of
constant data.
> Re. #3, `ecl -o <executable -link <object>` works, but only after
> producing the object file, which still
> requires all the manual steps mentioned because `ecl -compile <lisp>`
> produces a FASL file, and `ecl -o
> <object> -compile <lisp>` gives the following error: (Provided
> `(ext:install-c-compiler)` is in your .eclrc,
> otherwise it just produces FASL output)
>
> LINK : fatal error LNK1149: output filename matches input filename
> 'C:\Users\ralphm\Temp\src\experiments\lisp\hello-ecl\hello.obj'
You have to use the flag "-s" which uses :system-p when compiling files.
Otherwise you are telling ECL to create an object file and then to create a
FASL file with the same name as the object file, which is obviously wrong.
Regarding ext;install-c-compiler, sorry, ECL defaults to the bytecodes
compiler because this is what is most easily used in Windows -- not
everybody has a C compiler. This may annoy you, but the reverse would annoy
other people.
In any case, it is not that hard to do this one-liner
$ ecl -eval '(ext:install-c-compiler)' -o foo.o -compile foo.lsp -s
;;; Loading #P"/Users/jjgarcia/lib/ecl-12.7.1/asdf.fas"
;;; Loading #P"/Users/jjgarcia/quicklisp/setup.lisp"
;;; Loading "/Users/jjgarcia/lib/ecl-12.7.1/cmp.asd"
;;; Loading "/Users/jjgarcia/lib/ecl-12.7.1/cmp.fas"
;;;
;;; Compiling foo.lsp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; End of Pass 1.
;;; Finished compiling foo.lsp.
;;;
$ ls foo.o
foo.o
Juanjo
--
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20121109/3d29aa79/attachment.html>
More information about the ecl-devel
mailing list