From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id BF44D7FA80 for ; Sat, 24 Oct 2015 12:05:44 +0200 (CEST) IronPort-PHdr: 9a23:vH7oLBUeDqQAPEYfd1cH+Nv49EzV8LGtZVwlr6E/grcLSJyIuqrYZhOPt8tkgFKBZ4jH8fUM07OQ6PC9HzRYqb+681k8M7V0HycfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aJBzzOEJPK/jvHcaK1oLsh730o8WbSj4LrQT+SIs6FA+xowTVu5teqqpZAYF19CH0pGBVcf9d32JiKAHbtR/94sCt4MwrqHwI6LoJvvRNWqTifqk+UacQTHF/azh0t4XXskyJdgyC6WcGVX1S2j9JCAjM4RWwFsP0syD6v+d5njKdMMLqV7cscTWk86pvDhTvjXFUGSQ+9TT+htZxgaQThhutqgY3l4fYeoCYMtJ4eb/eO9QASjwSDY5qSyVdD9bkPMM0BO0bMLMd9tGlqg== Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=adrien@notk.org; spf=PermError smtp.mailfrom=adrien@notk.org; spf=None smtp.helo=postmaster@nautica.notk.org Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: PermError (mail3-smtp-sop.national.inria.fr: cannot correctly interpret sender authenticity information from domain of adrien@notk.org) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ArBQDnVitW/5NHeVtdgzZUb8AhIYVyCgKBLDsRAQEBAQEBAQGBCYIrggcBAQEDASNLCwULCxIGAgIFEw4CAg8FGB0BEy6IDQwJsxOSOAEBAQEGAQEBARsEgSKFVYN4gQaEOwEBUAeCaTGBFAWWNoUch34IW5tUNyyCER2BVzw0hViBQAEBAQ X-IPAS-Result: A0ArBQDnVitW/5NHeVtdgzZUb8AhIYVyCgKBLDsRAQEBAQEBAQGBCYIrggcBAQEDASNLCwULCxIGAgIFEw4CAg8FGB0BEy6IDQwJsxOSOAEBAQEGAQEBARsEgSKFVYN4gQaEOwEBUAeCaTGBFAWWNoUch34IW5tUNyyCER2BVzw0hViBQAEBAQ X-IronPort-AV: E=Sophos;i="5.20,192,1444687200"; d="scan'208";a="151626844" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-GCM-SHA384; 24 Oct 2015 12:05:43 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id E9C75C009; Sat, 24 Oct 2015 12:05:42 +0200 (CEST) Date: Sat, 24 Oct 2015 12:05:42 +0200 From: Adrien Nader To: "Soegtrop, Michael" Cc: Xavier Leroy , "caml-list@inria.fr" Message-ID: <20151024100542.GA6660@notk.org> References: <0F7D3B1B3C4B894D824F5B822E3E5A172CE32E38@IRSMSX102.ger.corp.intel.com> <562A5C92.50206@inria.fr> <0F7D3B1B3C4B894D824F5B822E3E5A172CE3315A@IRSMSX102.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0F7D3B1B3C4B894D824F5B822E3E5A172CE3315A@IRSMSX102.ger.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] Effect of Windows LLP64 architecture on 64 bit MingW OCaml 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