Cross-Compiling Common Lisp for Windows(fosskers.ca)
fosskers.ca
Cross-Compiling Common Lisp for Windows
https://www.fosskers.ca/en/blog/cl-windows
10 comments
Here's a response:
This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:
The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.
For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.
Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.
The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.
Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.
This is a really clean approach. I've been doing something similar for my CL game engine, but I hit a few gotchas worth mentioning:
The Wine overhead for the REPL is surprisingly minimal - maybe 50-100MB extra RAM and no noticeable latency. The real pain point is when you need Windows-specific debugging. Wine's implementation of Windows debugging APIs is... spotty. If you hit a nasty FFI crash, you're basically flying blind compared to native development.
For the DLL loading, one trick I learned: use GetProcAddress equivalents through CFFI instead of relying on load-time symbol resolution. This lets you gracefully handle missing functions between different Windows versions without crashing on startup. Particularly useful if you're targeting both Windows 7 holdouts and Windows 11.
Also worth noting: if you're distributing commercially, the mingw runtime has some licensing quirks. The "posix" threading model links against winpthread which is GPL (with exceptions), while the "win32" model avoids this but lacks some C++11 features. For pure C code it's usually fine, but check your dependencies.
The 40MB executable size is brutal though. I ended up using UPX on the Windows builds which gets it down to ~12MB with decent decompression speed. Just add upx --best aero-fighter.exe to your build script. Some antivirus software gets twitchy about UPX-compressed executables, but it's generally fine for games.
Anyone know if SBCL's Windows fork has plans to add core compression? Seems like low-hanging fruit given how well it works on other platforms.
Thanks for this! I'll look into compressing the `.exe` down.
With regards to licensing, I think I'm okay. Raylib itself is permissive, and I own the rest of the dependencies (save two - one is MIT and the other is public domain).
With regards to licensing, I think I'm okay. Raylib itself is permissive, and I own the rest of the dependencies (save two - one is MIT and the other is public domain).
You're responding to an AI post.
[deleted]
Wouldn't Cosomoplitan be the true cross-compiling in this case?
https://github.com/jart/cosmopolitan
https://github.com/jart/cosmopolitan
no GUI lib for cosmopolitan libc yet, afaik.
I'm going to be that guy and say "this isn't cross-compiling." I was thinking "Why not just use Wine" when I clicked on the link, and that's what they are doing.
The approach is somewhat interesting: They model the different platforms the code will run on as classes and set them up to inherit from one another, which drives the optimization possibilities, register allocations and the code generation. Because of the inheritance, they claim that porting to neighboring CPU families is easy since they don't have to duplicate the code for the instruction set mappings, etc. and only specialize the certain parts that are different.