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

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

[Soegtrop, Michael]

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

Dear Adrien,

thanks for your detailed answer! I will do more experiments and then send a summary and request some doc extensions/updates as you suggested below.

Regrading the \r\n problem: the tr -d '\r' can be integrated into the runtest script as attached, so it would be only in one place. But for the time beeing I am using the supplied makefiles - as I said using configure was just a mistake. I did too much GTK building recently ;-) Still I got fairly far with the configure approach with just a few minor changes.

Regarding flexlink/flexdll: This somehow is in the configure scripts, but it doesn't seem to work. When building with configure, the system tries to link with gcc rather than flexlink and the flexlink defined symbols are missing then. I hacked it into the makefiles to get forward. I didn't find out what exactly went wrong between configure and make. The mkexe define seems to be used in different ways.
 
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

[-- Attachment #2: runtest --]
[-- Type: application/octet-stream, Size: 1143 bytes --]

#!/bin/sh

#########################################################################
#                                                                       #
#                                 OCaml                                 #
#                                                                       #
#            Xavier Leroy, projet Cristal, INRIA Rocquencourt           #
#                                                                       #
#   Copyright 1995 Institut National de Recherche en Informatique et    #
#   en Automatique.  All rights reserved.  This file is distributed     #
#   under the terms of the GNU Library General Public License, with     #
#   the special exception on linking described in file ../../LICENSE.   #
#                                                                       #
#########################################################################

if test "$verbose" = yes; then
echo "runtest: $cc -o tst $* $cclibs" >&2
$cc -o tst $* $cclibs || exit 100
else
$cc -o tst $* $cclibs 2> /dev/null || exit 100
fi

resultval=`./tst`
resultcode=$?

echo "$resultval" | tr -d '\r'
exit $resultcode

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

[Adrien Nader]

On Mon, Oct 26, 2015, Soegtrop, Michael wrote:
> > The Makefile.nt system exists mainly for the MSVC build. I also think that the
> > mingw build would be better done with the Makefiles.
> 
> I see. I guess an Ocaml build is very special, but did the Ocaml community ever consider cmake or bakefiles? The main advantage, besides supplying cross platform builds in a maintainable way, is that they also supply IDE project files, which makes it more comfortable to work on Ocaml itself, especially libraries.

There are several things to take into account here:
- history
- migration cost
- availability of something in either cmake or bmake that fits the needs
  of OCaml and of the compiler (I am fairly sure there aren't any, at
  least in cmake)
- cost of cleaning 20 years of growth (this applies to anything related
  to this subject since it is often difficult to understand the
  differences between .nt and non .nt files)

-- 
Adrien Nader

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

[Soegtrop, Michael]

Dear Gerd,

> Officially, the OCaml build doesn't support that host arch <> build arch.
> (Remember, this is a feature gcc supports, and nothing "a compiler needs to
> be aware of".)
> 
> But anyway, the situation is a little bit different than for a C compiler. OCaml
> uses bytecode for bootstrapping, and you can e.g. run the bytecode
> executables built for arch X on arch Y with the ocamlrun for arch Y. So, if you
> wanted, you can have host <> build on your own.

All true, but what counts is how easy it is to do this in practice. In the end you say it is not required to have this because it is more or less trivial for Ocaml. But in practice it doesn't look like this is really the case.

Btw.: I think we are talking about host<>target. Build (in gcc terms this is the OS on which gcc is build) is likely almost always Cygwin and I don't see a good reason to change this.

> That said, this is only the explanation why host<>build was so far not of
> special interest.

I guess host<>target would be easiest to get opam to work and opam would be best for those who are mostly working on Linux but want to support Windows binaries.

> The Makefile.nt system exists mainly for the MSVC build. I also think that the
> mingw build would be better done with the Makefiles.

I see. I guess an Ocaml build is very special, but did the Ocaml community ever consider cmake or bakefiles? The main advantage, besides supplying cross platform builds in a maintainable way, is that they also supply IDE project files, which makes it more comfortable to work on Ocaml itself, especially libraries.

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

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

[Soegtrop, Michael]

Dear David,

> 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 fully agree. But I think full native windows Ocaml compilers are also required. E.g. recent Coq requires an Ocaml compiler at run time and one doesn't want to require Cygwin for this. That's the reason why I started to think what it would take to get to a gcc like configure with separate build, host and target configure parameters. In the end one might want to have 3 different build variants:

-build=x86_64-pc-cygwin
-host= x86_64-pc-cygwin
-target=x86_64-pc-cygwin
As far as I can tell this variant works fine and also opam works in this configuration out of the box. Useful for people working on GPL projects or can afford a lawyer to figure out the licensing details or a want to buy a cygwin commercial license.

-build=x86_64-pc-cygwin
-host= x86_64-pc-cygwin
-target=x86_64-w64-mingw32
This is what you mentioned above and, assuming opam works, would be a good work for environment for everybody who is mostly working on Linux and just wants to supply Windows binaries of his application with minimal effort.

-build=x86_64-pc-cygwin
-host=x86_64-w64-mingw32
-target=x86_64-w64-mingw32
This works by using the supplied separate makefiles and is required for those who mainly work on Windows and for applications which need an Ocaml compiler at run time (like Coq 8.5).

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

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

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

Am Samstag, den 24.10.2015, 09:29 +0000 schrieb Soegtrop, Michael:
> 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?

Exactly. There is also win32unix/write.c:

CAMLprim value unix_write(value fd, value buf, value vofs, value vlen)
{
  intnat ofs, len, written;
  DWORD numbytes, numwritten;
  char iobuf[UNIX_BUFFER_SIZE];
  DWORD err = 0;

  Begin_root (buf);
    ofs = Long_val(vofs);
    len = Long_val(vlen);

The organization of the sources is a bit tricky there. Some files are
copied from unix/ to win32unix/ and some aren't, like write.c.

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

Officially, the OCaml build doesn't support that host arch <> build
arch. (Remember, this is a feature gcc supports, and nothing "a compiler
needs to be aware of".)

But anyway, the situation is a little bit different than for a C
compiler. OCaml uses bytecode for bootstrapping, and you can e.g. run
the bytecode executables built for arch X on arch Y with the ocamlrun
for arch Y. So, if you wanted, you can have host <> build on your own.

Windows in particular is very special, because the distinction
build/host makes only sense for some aspects, as you can run the host
executables on the build system. You mention paths, but this is also
non-critical, because Cygwin also accepts native paths with forward
slashes. What remains is finally LF vs CR/LF, but this can also be
addressed by other means.

That said, this is only the explanation why host<>build was so far not
of special interest.

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

The Makefile.nt system exists mainly for the MSVC build. I also think
that the mingw build would be better done with the Makefiles.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[David Allsopp]

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

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

[Soegtrop, Michael]

Dear Gabriel,

I think the information that dedicated 64 bit makefiles are available is important. We do things which require a lot of RAM, so 32 bit won't work. Also many people will think that 32 bit toolchains are outdated and it doesn't make a good impression if the docs mention a 32 bit windows build but not a 64 bit windows build. I will first test how well the 64 bit mingw stuff works and the request a change as you suggested.

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

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

[Gabriel Scherer]

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

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

[Adrien Nader]

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

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

[Soegtrop, Michael]

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

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

[Xavier Leroy]

On 23/10/15 15:57, Soegtrop, Michael wrote:
> I wonder what differences exist between a 64 bit Linux Ocaml and a 64 bit
> MingW Ocaml. 64bit Windows and MingW64 are what is called LLP64, that is int
> and long are 32 bit and only long long, size_t and pointers are 64 bit as in
> 32 bit Windows. MingW has to follow this convention, otherwise it would be
> incompatible to the Windows headers. But 64 bit Linux tends to be LP64, that
> is int is 32 bit, but long is 64 bit.

That's right.  But the OCaml runtime system abstracts over this
difference, so that you get the same behaviors under Win64 and under
all other 64-bit systems (of the LP64 kind).

> The Ocaml C code doesn’t seem to use
> size abstraction types (like int32, int64)

It does, and even more so in the development version.  The key
abstraction types are "intnat" and "uintnat", designating an integer
type that has the same size as a pointer.  You get those types as
soon as your code includes <caml/mlvalues.h>.

You may have been confused by the use of "long" in the names of the
macros "Val_long" and "Long_val".  Indeed, in the past they used
"long" as "the integer type as big as a pointer type", but since Win64
support was introduced, they actually use type "intnat".

Hope this answers your question.

- Xavier Leroy

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

[Soegtrop, Michael]

[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]

Dear Ocaml Users,

I wonder what differences exist between a 64 bit Linux Ocaml and a 64 bit MingW Ocaml. 64bit Windows and MingW64 are what is called LLP64, that is int and long are 32 bit and only long long, size_t and pointers are 64 bit as in 32 bit Windows. MingW has to follow this convention, otherwise it would be incompatible to the Windows headers. But 64 bit Linux tends to be LP64, that is int is 32 bit, but long is 64 bit. The Ocaml C code doesn't seem to use size abstraction types (like int32, int64), so I wonder what effect this has. Is a 64 bit MingW Ocaml somehow half 32 bit and half 64 bit as MingW C, or does it behave in the same way as a 64 bit Linux Ocaml? If MingW64 bit Ocaml is equivalent to Linux64 Ocaml, it would be interesting to know how this is done (there are a lot of longs e.g. in byterun).

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

[-- Attachment #2: Type: text/html, Size: 3086 bytes --]