caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Gerd Stolpmann <info@gerd-stolpmann.de>
To: "Soegtrop, Michael" <michael.soegtrop@intel.com>
Cc: Xavier Leroy <Xavier.Leroy@inria.fr>,
	"caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Effect of Windows LLP64 architecture on 64 bit MingW OCaml
Date: Sat, 24 Oct 2015 13:16:38 +0200	[thread overview]
Message-ID: <1445685398.4567.70.camel@e130.lan.sumadev.de> (raw)
In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CE3315A@IRSMSX102.ger.corp.intel.com>

[-- 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 --]

  parent reply	other threads:[~2015-10-24 11:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-23 13:57 Soegtrop, Michael
2015-10-23 16:13 ` Xavier Leroy
2015-10-24  9:29   ` Soegtrop, Michael
2015-10-24 10:05     ` Adrien Nader
2015-10-24 10:09     ` Gabriel Scherer
2015-10-24 10:54       ` Soegtrop, Michael
2015-10-24 10:59     ` David Allsopp
2015-10-26  8:25       ` Soegtrop, Michael
2015-10-24 11:16     ` Gerd Stolpmann [this message]
2015-10-26  8:42       ` Soegtrop, Michael
2015-10-26 19:04         ` Adrien Nader
2015-10-24 10:49 Soegtrop, Michael

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1445685398.4567.70.camel@e130.lan.sumadev.de \
    --to=info@gerd-stolpmann.de \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=michael.soegtrop@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).