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

[David Allsopp <dra-news@metastack.com>]

Michael Soegtrop 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. 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.

You need to look in otherlibs/win32unix for the Windows sources. otherlibs/win32unix/write.c has intnat.

> 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.
> - bad uses of long in auto-aux files, e.g. endian.c
> - The flexlink handling needs some fixes
> - 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.
> 
> 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.

FWIW, this might be pulling itself into my native Windows OPAM port - we're interested in Windows/Cygwin cross-compilers (i.e. ocamlopt being a Cygwin executable which outputs native Windows executables using mingw64/msvc and vice versa) and it makes sense to unify the build process at the same time as trying to do that.

I did some preliminary work too a few years ago getting configure's output to match the template files in config/ - a good initial step would be to keep Makefile.nt but "hide" it from the user by having configure set which Makefile actually gets called at the toplevel (i.e. you say make world and configure sets things up so that that is actually make -f Makefile.nt world if necessary). Quite apart from breaking mainline OCaml, the change will be pretty invasive to forks and other branches being worked on! 


David