[wg-windows] Improving the state of OCaml on Windows

Adrien Nader an at satcom1.com
Mon Jun 1 13:27:29 BST 2015


Hi,

Sorry for breaking the threading and having a poor formatting: I
subscribed recently to the mailing-list and had to read the archives.

 From Edwin Török:

> Cygwin64 unreliability
> ----------------------
>
> I don't know if the bug is in Windows, Cygwin64 or my VM configuration
> but the build system itself crashes a lot and randomly
> (there seems to be plenty of RAM available).
> Even things like make.exe or rm.exe crash with: segfault, fork:
> resource unavailable, exit code -1073741819.
> Restarting the cygwin shell helps sometimes but the errors are soon
> back, even when using just make -j1.
> The situation was bad enough that I had to repeat the build  4-5 times
> until it finally succeeded as it kept crashing in different places.
> Someone else tried WODI32 and didn't see such errors there, so that
> seems like a more reliable build system.
> Was about to report this as a bug in Cygwin64, but next week WODI was
> shutdown so that ended my Windows testing as well.

I just opened a bug on mantis after trying to build under Cygwin64 for
cygwin64. I actually got two major issues.
First, the simple one: lots of Cygwin-specific C code doesn't work
because it is behind #ifdef __CYGWIN32__ and that define is only for 32
bits.
The more annoying one: no flexlink binaries for Cygwin64. My
understanding is that there should be a flexlink_cygwin64.o file or
similar but currently it tries to use the 32bits .o and fails (it says
"undefined references" but that's expected for such a case).

You mention you used Cygwin64 quite some time ago. It is fairly young so
you probably tried it at a fairly early stage. With a recent
installation, I also got weird stuff: I couldn't pipe code to 'ocaml
-stdin', make wouldn't always redo .PHONY rules and not all toplevel
expressions in OCaml were always evaluated it /seems/ (that's something
I got when cross-compiling but never really understood).

Overall I would say the port is not in a good-enough shape to announce
as supported, even with limitations. That doesn't imply anything about
the Windows 64 port a priori.

Nevertheless it is important to have cygwin ports. For a sane system, we
need to avoid having a cygwin shell than spawns an non-cygwin executable
(build tool) which then spawns a cygwin bash which spawns a non-cygwin
executable (ocamlopt for instance). It's better to remain in the same
realm (no matter which one) for as many consecutive steps as possible
and at least some builds will definitely continue to require a unix
environment.

> Is there a way to have the build system and ocamlfind/ocamlopt/ocamlc
> agree on the format of paths?
> (i.e. either both of them are Cygwin or both of them native Win32 apps
> but not a mix)

I believe we should focus on cross-compilation to solve that. Currently
we need a mutant approach because OCaml's build on Cygwin for use
outside of Cygwin is itself a mutant.
If we had cross-compilation, we would have one ocamlbuild.exe (for
instance) that runs as a cygwin executable and one that runs as a native
windows executable; the former would use POSIX-style paths while the
latter would use Windows-style paths. There would be a clear distinction
and no need to have both usable at the same time.

By the way, C:/foo/bar is a perfectly valid Windows paths and avoids
many troubles with backslashes. Don't fear using forward slashes in paths.

> > - Discuss the state of cross compilation to Windows.
>
> This seems similar to the Android cross-compilation repository:
> https://github.com/vouillon/opam-windows-repository

It's also quite different: Makefile vs. Makefile.nt is a big issue in
practice. I've worked on reducing the differences but there are still many.
I believe it is a top priority to merge the two because otherwise it
means working on something that will have to be undone and re-done when
we finally merge the two set of makefiles. Merge conflicts have been a
huge pain for me when I last actively worked on the compiler build
system, to the point it cost several days, if not weeks and probably
prevented me from finishing the work.

--
Adrien Nader

[http://www.satcom1.com/marketing/banner/PAS_sig_banner.jpg]<http://www.satcom1.com/event/paris-airshow-2015-hall-4-e15/>


More information about the wg-windows mailing list