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 17CA77F860 for ; Thu, 20 Feb 2014 17:53:41 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of Xavier.Leroy@inria.fr) identity=pra; client-ip=212.27.42.1; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="Xavier.Leroy@inria.fr"; x-sender="Xavier.Leroy@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of Xavier.Leroy@inria.fr) identity=mailfrom; client-ip=212.27.42.1; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="Xavier.Leroy@inria.fr"; x-sender="Xavier.Leroy@inria.fr"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp1-g21.free.fr) identity=helo; client-ip=212.27.42.1; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="Xavier.Leroy@inria.fr"; x-sender="postmaster@smtp1-g21.free.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkBALQyBlPUGyoBnGdsb2JhbABZhxe9DIEQFg4BAQEBAQYNCQkUKIIlAQEEASMwExIGCwsSCAIFDAoLAgIJAwIBAgE3AQ0TCAEBF4diDK0GoUEXgSmNQgqCZYFJBJgwhkePCw X-IPAS-Result: AnkBALQyBlPUGyoBnGdsb2JhbABZhxe9DIEQFg4BAQEBAQYNCQkUKIIlAQEEASMwExIGCwsSCAIFDAoLAgIJAwIBAgE3AQ0TCAEBF4diDK0GoUEXgSmNQgqCZYFJBJgwhkePCw X-IronPort-AV: E=Sophos;i="4.97,513,1389740400"; d="scan'208";a="59463955" Received: from smtp1-g21.free.fr ([212.27.42.1]) by mail2-smtp-roc.national.inria.fr with ESMTP; 20 Feb 2014 17:53:40 +0100 Received: from [192.168.1.2] (unknown [82.237.71.191]) by smtp1-g21.free.fr (Postfix) with ESMTP id 96732940190 for ; Thu, 20 Feb 2014 17:53:36 +0100 (CET) Message-ID: <5306330F.1020401@inria.fr> Date: Thu, 20 Feb 2014 17:53:35 +0100 From: Xavier Leroy User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <20140218185032.GA20593@notk.org> In-Reply-To: <20140218185032.GA20593@notk.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] [RFC] Remaining changes for cross-compilation support in OCaml 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. > *** 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