Cross-building Racket applications for 64bit Windows on Linux

[Dominik Pantůček]

Hello Racketeers,

although I am developing Racket applications on Linux, our customers are
usually running Windows. The good thing about Racket (and racket/gui
especially) is that it requires virtually no OS-specific code for many -
even non-trivial - tasks. However it is not that straightforward to
produce binaries for different target platform.

Since last summer, we have been successfully using wine and Racket
Windows builds to create 32bit binaries. However with Racket BC it was
impossible to make it work with 64bit Windows builds. This is still the
case even with latest snapshots and latest wine bundled with Ubuntu 20.04.

It turns out, that Racket CS works flawlessly under wine - including
raco.exe exe. And with the latest patches[1] (thanks Matthew and
DaLynX), it is possible to produce working 64bit Windows binaries from
Racket programs on Linux using wine.

As my work is heavily CPU- and memory-bound, the 32bit address space
limit was quite a limit.

However, once we tried to embed the build process into our
(Gitlab-based) CI/CD, we failed miserably. Combining wine and Racket
windows builds (7.7.0.6 snapshots from University of Utah) turned out to
be a terrible nightmare under Docker.

On my workstation, it is absolutely straightforward:

rm -fr ~/.wine # Do not try this without backing up, if you need it
wine racket-7.7.0.6-x86_64-win32-cs.exe

Now just click next next next with the installer and you are ready.
Building a 64bit Windows binary is just a matter of single:

wine ~/.wine/drive_c/Program\ Files/Racket-7.7.0.6/raco.exe exe --gui
--embed-dlls program.rkt

Of course, any packages needed have to be installed using raco.exe pkg
in the same wine prefix.

But when you take the ~/.wine prefix and try to run it under docker,
nothing works at all and tracing what is happening is extremely
difficult with very cryptic results.

We ruled out X11 dependency - raco.exe works just fine after I `unset
DISPLAY` on my workstation. And the results in Docker are no different
with Xvfb installed and running. We got to a point where the raco.exe
actually starts as a process under wine in Docker and it silently fails
upon startup.

Any ideas where to look and what to test? I strongly assume Racket is
not the root cause of the problem here, but rather the combination of
wine under Docker. However, Racket sometimes uses an OS-specific
trickery so I am sort of hoping that the described behavior rings a bell
for someone :)


Cheers,
Dominik

[1]
https://github.com/racket/racket/commit/61cefe693a047e22ca44752eafb9eb9e2e65409f

[Matthew Flatt]

Have you already tried using `raco exe` on Linux (i.e., using Racket
for Linux) but generating Windows executables?

https://docs.racket-lang.org/raco/cross-system.html


Note that the "tarball" distributions at places like

https://download.racket-lang.org/releases/7.7/

can be handy for setting up a <cross-dir>.

[Matthew Flatt]

Thinking about this a little more, I don't think all the pieces are in
place for CS. At least, I don't remember setting up all the pieces...

The extra piece needed for Racket CS is a Chez Scheme cross-compiler
that runs on Linux but produces machine code for Windows. That can be
done --- and it is done, because our distributions for Windows are
built on Linux (without wine). But I don't think the cross compilers
are stashed anywhere right now, and we'll need to offer NxM cross
compilers for N host systems and M target systems.

So, if building on a Linux target for Windows works for BC (which is a
different question than trying to run BC on wine), then we can start
thinking about how to fill in the last NxM pieces for CS.

> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/racket-users/20200523102531.1f5%40sirmail.smt
> p.cs.utah.edu.

[Dominik Pantůček]

I'll try with 3m. I am a bit skeptical here - as the resulting
program.exe is about 150M when properly build and apparently has to
include a lots of native DLLs. But reading the documentation (again)
makes me think that generally it should work.

Technically the byte-code should be platform-independent for 3m and then
it is just a matter of pre-prending the right binary and packing-in the
libraries. I will definitely look into that.


Thank you!

Dominik