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

[Adrien Nader]

On 06/01/2015 02:27 PM, Adrien Nader wrote:
> 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.

I tried the same thing with Cygwin 32 bits on Monday and almost
everything worked at once and more importantly, there were no quantum
physics involved: thing either worked or not.

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