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 On 23. 05. 20 18:38, Matthew Flatt wrote: > 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. > > At Sat, 23 May 2020 10:25:31 -0600, Matthew Flatt wrote: >> 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>. >> >> >> At Sat, 23 May 2020 17:39:58 +0200, Dominik Pantůček wrote: >>> 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/61cefe693a047e22ca44752eafb9eb9e2e65409 >>> f >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/racket-users/20200523102531.1f5%40sirmail.smt >> p.cs.utah.edu. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/acefe5ca-33b4-259e-3e54-d3d84ff3542c%40trustica.cz.
