Re: [Caml-list] Effect of Windows LLP64 architecture on 64 bit MingW OCaml

[Adrien Nader <adrien@notk.org>]

On Sat, Oct 24, 2015, Soegtrop, Michael wrote:
> Dear Xavier,
> 
> yes, it answers my question, thanks! Andreas Hauptmann gave a similar answer before, but apparently as private mail. So let me post my reply here on the list:
> 
> Dear Andreas,
> 
> thanks for the pointers and details! Because the web doc is way outdated (https://ocaml.org/docs/install.html states there is just a 32 bit mingw build) I mistakenly tried to build mingw64 with configure and stumbled over a few bad uses of long in auto-aux stuff.

Been some time but I don't think the build uses the configure script,
i.e. you're supposed to use one of the pre-made config files. It mostly
works but you don't get actual full support.
As for the availability of only a 32 bit build, as far as I can tell
this is because it takes time to do and test these builds and it is only
volunteer work.

> But I agree that the main part of Ocaml looks clean in this respect. Just some libraries look a bit fishy, e.g.
> 
> CAMLprim value unix_write(value fd, value buf, value vofs, value vlen) {
>   long ofs, len, written;
>   int numbytes, ret;
>   char iobuf[UNIX_BUFFER_SIZE];
> 
>   Begin_root (buf);
>     ofs = Long_val(vofs);
>     len = Long_val(vlen);
> 
> This assignment of Long_val to a long doesn't seem to be correct. Or is this function just used for Linux? There are just 190 occurrences of \blong\b in the whole sources. It might make sense to remove all such uses outside of OS abstraction files.

long should be enough for file offsets everywhere when large file
support stuff isn't enabled.
That has been available in mingw-w64 (not mingw.org) only fairly
recently (compared to the existence of the ocaml windows port) and I
don't think it is being used in OCaml. Also, note that enabling it
properly is deeply annoying because the combination of defines to use is
almost impossible to understand (and then defines stat(), triggering
conflicts everywhere).

See https://gnunet.org/sorting-out-stat-thing for more explanations.

I also concur that it wouldn't hurt to review some more bits of the code
inside the compiler sources. Until now things have worked fine and the
developer time has been sucked in build system changes more than
compiler or library code.

> Btw.: The configure mechanism is not that bad for Mingw builds on Cygwin, if host, target and prefix are set properly. The main problems are:
> 
> - config/auto-aux/runtest and its users get confused by Mingw test apps returning strings terminated with \r\n instead of \n. Piping the output through tr -d '\r' fixes this.
This is most probably not an issue with mingw or ocaml but with the
posix-ish environment you use (msys*/mingw/interix[if you're crazy]).

IIRC only Cygwin host is officially supported.
This can definitely give the \r\n issue.
MSYS will however translate these to \n.
However MSYS2 won't (msys2 is similar to msys but based on a more recent
cygwin codebase).

I can't think of a very good solution to this. tr -d works well but
seems a bit kludgy. But it works really well.

> - bad uses of long in auto-aux files, e.g. endian.c
As I said, I think the whole configure stuff still isn't (officially)
supported for Windows. Also note that such things are currently
frequently changing and it's better to look at the latest development
sources, bug reports and patches (and there was something related to
that on this mailing-list a few days ago).

> - The flexlink handling needs some fixes
Could you be more specific?

> - It is way odd that there is no -build option to configure like with gcc. A compiler build needs to be aware of 3 OSes: the one on which the compiler is build, the one on which the built compiler runs and the one for which it generates code. For gcc all 3 are configurable. Some configure/make things are clearer and easier  if all 3 OSes are known. E.g. pathes tend to be different on the build and host OS when building a Mingw compiler on Cygwin.
-build isn't very useful in practice. One notable exception that I've
seen is with msys2 which uses its own triplet (I don't think it's
upstream) and likes to confuse build systems with its reliance on an
infinite amount of heuristics.

If you can come up with a use-case (and therefore at least one
test-case), there probably won't be any issue with adding it.

> I think it might be not so much work to get rid of the separate make files and use configure for mingw and cygwin builds as well.

Do you mean Makefile.nt? It's actually a bit of work. Should be less
than it used to be but still something fairly tedious and an easy way to
break the build. Fortunately, the various components now build mostly
independently which makes changes easier since they are more
self-contained.

-- 
Adrien Nader