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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

It's not that the page is "outdated", rather that there is the
information there that people decided to put there, on the basis of
the use-cases that they tried personally and could get to work
reliably. If nobody seriously tried to streamline mingw64 support
before, nobody got to document it (which seems reasonable given the
few hurdles you report).

You should feel free to send patches to the website information (from
any page on the website, the pen icon in the top-right corner will get
you to the corresponding file in the version control system, ready to
edit through github) or the compiler build system to improve your
preferred corner of Windows support.

On Sat, Oct 24, 2015 at 11:29 AM, Soegtrop, Michael
<michael.soegtrop@intel.com> 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.
>
> 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.
>
> Best regards,
>
> Michael
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
> Chairperson of the Supervisory Board: Tiffany Doon Silva
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs