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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D25297F860 for ; Fri, 21 Feb 2014 02:45:04 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of berenger@riken.jp) identity=pra; client-ip=134.160.33.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of berenger@riken.jp designates 134.160.33.175 as permitted sender) identity=mailfrom; client-ip=134.160.33.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="berenger@riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@postman.riken.jp designates 134.160.33.175 as permitted sender) identity=helo; client-ip=134.160.33.175; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="berenger@riken.jp"; x-sender="postmaster@postman.riken.jp"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlwBAFevBlOGoCGvnGdsb2JhbABZhxe6DYMGgScOAQEBAQEICwkJFCiCJQEBBSMVLhIRCxIGAgIFDAoLAgIJAwIBAgE3AQ0TCAEBF4dqrByhNBeBKY1CCoJlgUkBA4lGjmqVYA X-IPAS-Result: AlwBAFevBlOGoCGvnGdsb2JhbABZhxe6DYMGgScOAQEBAQEICwkJFCiCJQEBBSMVLhIRCxIGAgIFDAoLAgIJAwIBAgE3AQ0TCAEBF4dqrByhNBeBKY1CCoJlgUkBA4lGjmqVYA X-IronPort-AV: E=Sophos;i="4.97,515,1389740400"; d="scan'208";a="59517150" Received: from postman3.riken.jp (HELO postman.riken.jp) ([134.160.33.175]) by mail2-smtp-roc.national.inria.fr with ESMTP; 21 Feb 2014 02:45:02 +0100 Received: from postman.riken.jp (postman3.riken.jp [127.0.0.1]) by postman.riken.jp (Postfix) with SMTP id AA82A3838116 for ; Fri, 21 Feb 2014 10:44:58 +0900 (JST) Received: from watson.prg.gsc.riken.jp (ipm04.gsc.riken.go.jp [134.160.83.74]) by postman.riken.jp (Postfix) with ESMTPA id 6DF5638201A4 for ; Fri, 21 Feb 2014 10:44:58 +0900 (JST) Message-ID: <5306AF9A.4070705@riken.jp> Date: Fri, 21 Feb 2014 10:44:58 +0900 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20140218185032.GA20593@notk.org> <5306330F.1020401@inria.fr> In-Reply-To: <5306330F.1020401@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.21.13315 Subject: Re: [Caml-list] [RFC] Remaining changes for cross-compilation support in OCaml On 02/21/2014 01:53 AM, Xavier Leroy wrote: > Hi Adrien, > >> Roughly one year ago, late Wojciech Meyer and I started working on the >> integration of a set of patches aimed at enabling the OCaml compiler to >> be used for cross-compilation. >> >> Some of the patches so far have caused issues to some people. > > s/some people/the core OCaml dev team/ > >> **************************** Further Goals **************************** >> - cross-compile the compiler: build a native Windows toolchain on Linux >> - canadian cross support: ${build}, ${target}, ${host} are all >> different, i.e. on Linux, build a toolchain that runs on Windows 64b >> but targets Windows 32b or a different architecture/OS like ARM Linux. > > That could be a nice touch if it's not too much extra work. The issue > was discussed at the last OCaml dev team meeting that Wojciech > attended, and we agreed that some scenarios were less important than > others, e.g. nobody really needs to compile from a 32-bit host for a > 64-bit target. > >> ****************************** Approach ****************************** >> *** A cross-compiler requires a native toolchain of the same version *** >> A working _native_ compiler toolchain of the _exact_ same version as the >> cross-toolchain is needed, both when building the cross-toolchain and >> when using it; the main reason was camlp4 but I believe it is still a >> valid restriction > > Perhaps less so now that camlp4 is split off. The alternative is to > configure for the host, populate boot/ with a ocamlrun and standard > library appropriate for the host, then reconfigure for the target, and > finish the build. > >> *** Give up the restriction to POSIX for makefiles *** >> Either remove compatibility with BSD makes, or move GNU-make-isms to >> "GNUMakefile", BSD-makes-isms to "BSDMakefile" and common data to >> "Makefile.common" with the GNU/BSDMakefile files being the >> "entrypoints". > > The unanimous message from the OCaml dev team is to commit on GNU make > and forget about compatibility with other variants of make. BSD > people will forgive us, and it looks like the only sane way to merge > the Unix and Windows makefiles and support all the cross-compilation > scenarios. Moreover, I think BSDs can install GNU make and that the corresponding command is simply gmake instead of make. >> *** Use configure-defined variables instead of "ocaml{c,opt}"... *** >> The creation of the cross-compiler will rely on a native toolchain on >> ${build}. As such, ./configure will locate that toolchain and store its >> paths. This forbids any call like "./ocamlopt"; everything must rely on >> the paths found by configure. > > See above: this might not be necessary. > >> *** Use Int64.t in the compiler instead of Nativeint *** >> Currently, OCaml uses Nativeint to handle all the integers in the code >> that is being compiled. The "native" is for ${build}, not for ${target}. >> With a 64b host and 32b target, OCaml will output its values over 64 >> bits in the assembly and ld will then complain and truncate them. >> Move to Int64.t instead and delay the conversion to the right bitness >> until code emiting. > > Constant propagation and maybe other passes of the compiler also need to > take bitsize into account. > > If you're going this way, it's not Int64 the appropriate substitute > for Nativeint: it's Targetint, defined as Int32 or Int64 depending on > target bitsize. (This can be expressed with first-class modules.) > > There might be other ways if we assume bitsize(host) >= bitsize(target). > >> *** For bytecode, assume C libraries contain the required primitives *** >> When doing linking for bytecode with -custom, OCaml will dlopen() the >> corresponding library and dlsym() the primitive as an early check for >> their availability at runtime. >> Quite obviously, this fails for cross-compilation and the only solution >> I can think of is to disable the check completely. > > Probably there is no choice. But it pains me to move link-time errors > to run-time (more exactly, program startup time). If we program in > OCaml rather than Python, it's also for the early error detection. > > - Xavier Leroy > -- Best regards, Francois Berenger.