[mkcl-devel] Native compilation on Windows
I just downloaded MKCL-1.1.0 & tried compiling a small "Hello, world" program on Windows without success. Here's what I tried: 1. Add "C:\Program Files\MKCL 1.1\bin" to my PATH. 2. Run `mkcl -not-fasl-p -compile hello.lisp` which produces lisp.o 3. Now what? I've tried to link using `gcc -o hello.exe hello.o -lmkcl_1.1.0` which produces an error: c:/program files/mkcl 1.1/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o): In function `main': /W64_4.5_180676-src/build-crt/../mingw-w64-crt/crt/crt0_c.c:18: undefined reference to `WinMain' collect2: ld returned 1 exit status I've also tried `mkcl -o hello.exe -link hello.o` which produces the following error: build-program failed: Unknown keyword :LISP-FILES Any help would be appreciated. Regards, Ralph
On Wed, Oct 24, 2012 at 10:24 AM, Ralph Möritz <ralph.moeritz@outlook.com>wrote:
I just downloaded MKCL-1.1.0 & tried compiling a small "Hello, world" program on Windows without success. Here's what I tried:
1. Add "C:\Program Files\MKCL 1.1\bin" to my PATH. 2. Run `mkcl -not-fasl-p -compile hello.lisp` which produces lisp.o 3. Now what? I've tried to link using `gcc -o hello.exe hello.o -lmkcl_1.1.0` which produces an error:
Such a direct call to gcc cannot work with a ".o" produced by the MKCL compiler (see [1] below as to why).
I've also tried `mkcl -o hello.exe -link hello.o` which produces the following error:
build-program failed: Unknown keyword :LISP-FILES
That instead should have worked! You have quite clearly hit a bug in MKCL-1.1.0. But you see, that access from the command line to the #'compiler:build-program facility is somewhat seldom used and has bit-rot without me noticing. I will fix it in the coming hours and that fix should be part of MKCL-1.1.1 (to be released soon I expect). Let me stress the point that such a use of MKCL on the command line, although supported, is somewhat atypical. Like other Common Lisp systems, MKCL is mostly used through a REPL, either MKCL's own default REPL (somewhat basic) or the REPL of SLIME (a much nicer one). Also, producing a full OS native executable is a fairly rare event since the typical user of MKCL will be building his CL world by loading (fasl or source) libraries at the REPL prompt. Were you knowingly testing this command line option or did you hit on it more or less by chance? In the second case I could suggest you some easy alternatives depending on your goal. Cheers, Jean-Claude Beaudoin [1] The ".o" object files produced by the MKCL native compiler are not quite basic C object files, they contain hooks that need to be called with a specific context at load time in order for its object code to integrate itself properly with the rest of the Common Lisp runtime system. The compiler:build-program facility provides the framework for this to happen properly.
On Wed, Oct 24, 2012 at 10:24 AM, Ralph Möritz <ralph.moeritz@outlook.com<mailto:ralph.moeritz@outlook.com>> wrote: I just downloaded MKCL-1.1.0 & tried compiling a small "Hello, world" program on Windows without success. Here's what I tried:
1. Add "C:\Program Files\MKCL 1.1\bin" to my PATH. 2. Run `mkcl -not-fasl-p -compile hello.lisp` which produces lisp.o 3. Now what? I've tried to link using `gcc -o hello.exe hello.o -lmkcl_1.1.0` which produces an error:
Such a direct call to gcc cannot work with a ".o" produced by the MKCL compiler (see [1] below as to why).
Ah! Thanks for elaborating.
I've also tried `mkcl -o hello.exe -link hello.o` which produces the following error:
build-program failed: Unknown keyword :LISP-FILES
That instead should have worked! You have quite clearly hit a bug in MKCL-1.1.0. But you see, that access from the command line to the #'compiler:build-program facility is somewhat seldom used and has bit-rot without me noticing. I will fix it in the coming hours and that fix should be part of MKCL-1.1.1 (to be released soon I expect).
Great, thanks.
Let me stress the point that such a use of MKCL on the command line, although supported, is somewhat atypical. Like other Common Lisp systems, MKCL is mostly used through a REPL, either MKCL's own default REPL (somewhat basic) or the REPL of SLIME (a much nicer one). Also, producing a full OS native executable is a fairly rare event since the typical user of MKCL will be building his CL world by loading (fasl or source) libraries at the REPL prompt. Were you knowingly testing this command line option or did you hit on it more or less by chance? In the second case I could suggest you some easy alternatives depending on your goal.
In my spare time I'm writing a chess engine. Chess engines are usually provided to users as statically linked native executables. Of course I'm using SLIME interactively during development, but I'd like to be able to build the executable from the command-line as well. Normally I use SBCL, but I'm experimenting with ECL & MKCL specifically to be able to produce native executables from my Lisp code. Regards, Ralph
On Thu, Oct 25, 2012 at 3:16 AM, Ralph Möritz <ralph.moeritz@outlook.com>wrote:
On Wed, Oct 24, 2012 at 10:24 AM, Ralph Möritz <ralph.moeritz@outlook.com<mailto:ralph.moeritz@outlook.com>> wrote: I just downloaded MKCL-1.1.0 & tried compiling a small "Hello, world" program on Windows without success. Here's what I tried:
1. Add "C:\Program Files\MKCL 1.1\bin" to my PATH. 2. Run `mkcl -not-fasl-p -compile hello.lisp` which produces lisp.o 3. Now what? I've tried to link using `gcc -o hello.exe hello.o -lmkcl_1.1.0` which produces an error:
Such a direct call to gcc cannot work with a ".o" produced by the MKCL compiler (see [1] below as to why).
Ah! Thanks for elaborating.
Yes I know, this should be clearly explained in the documentation...
... In my spare time I'm writing a chess engine. Chess engines are usually provided to users as statically linked native executables. Of course I'm using SLIME interactively during development, but I'd like to be able to build the executable from the command-line as well. Normally I use SBCL, but I'm experimenting with ECL & MKCL specifically to be able to produce native executables from my Lisp code.
Well, in that case all I can add is: Thank you very much for the bug report and I am working on a fix right now.
On Wed, Oct 24, 2012 at 10:24 AM, Ralph Möritz <ralph.moeritz@outlook.com>wrote:
I just downloaded MKCL-1.1.0 & tried compiling a small "Hello, world" program on Windows without success. Here's what I tried:
1. Add "C:\Program Files\MKCL 1.1\bin" to my PATH. 2. Run `mkcl -not-fasl-p -compile hello.lisp` which produces lisp.o 3. Now what? I've tried (...) `mkcl -o hello.exe -link hello.o` which produces the following error:
build-program failed: Unknown keyword :LISP-FILES
MKCL 1.1.1 is now available (on common-lisp.net) with the fix for that problem. So you will have now the problem of running "hello.exe" per se. In that you are likely to hit against two annoyances: (1) location of MKCL's runtime object code shared library, (2) location of MKCL's loadable modules directory. (1) can be taken care of by proper setting of the "path" environment variable on MS-Windows and by some equivalent setting of LD_LIBRARY_PATH on Linux and other unixes. (2) is usually found as a relative path from the MKCL startup executable, i.e: "<executable location>\..\lib\mkcl-1.1.1". So, given an executable of say "c:\foo\bar\hello.exe" then MKCL will look for its support files/modules in "c:\foo\bar\..\lib\mkcl-1.1.1". If that fails then MKCL tries to look at its logical device "SYS" which has a default value set at MKCL's build time which can be overridden through environment variable MKCL_LIBDIR. Since it is most likely that "hello.exe" will not reside at the required relative path of the needed loadable modules directory, then the use of MKCL_LIBDIR is most likely necessary. With MKCL 1.1.1 and earlier, an invalid value of MKCL_LIBDIR (combined with an unlucky executable location) will most likely manifest itself through the cryptic message: MKCL: Unable to open Unicode character database file: c:\<your path here>\lib\mkcl-1.1.1\ucd.dat In MS-Windows, the solution will be to do something like: set MKCL_LIBDIR=c:\<proper path here>\lib\mkcl-1.1.1 or to do the equivalent environment variable setting on Linux and others. The "ucd.dat" file and the MKCL_LIBDIR environment variable are legacy devices whose role, location and proper existence will need to be significantly reassessed (soon?) but can be accommodated with for the time being. I hope this is useful for you. Cheers, Jean-Claude Beaudoin
participants (2)
-
Jean-Claude Beaudoin -
Ralph Möritz