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 6F8B47F860 for ; Fri, 21 Feb 2014 12:56:50 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of benoit.vaugon@gmail.com) identity=pra; client-ip=74.125.82.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benoit.vaugon@gmail.com"; x-sender="benoit.vaugon@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of benoit.vaugon@gmail.com designates 74.125.82.171 as permitted sender) identity=mailfrom; client-ip=74.125.82.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benoit.vaugon@gmail.com"; x-sender="benoit.vaugon@gmail.com"; 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@mail-we0-f171.google.com) identity=helo; client-ip=74.125.82.171; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="benoit.vaugon@gmail.com"; x-sender="postmaster@mail-we0-f171.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgCAO89B1NKfVKrlGdsb2JhbABZg0GDWr02gREWDgEBAQEHCwsJEiqCJQEBBSMPAQUIARscAQEDDAYFCw0CAgUMCgsCAgkDAgECARERAQUBDgENBg0BBwEBF4dVAQMRBAEInw2MDFODDpUwChknDWSGeBEBAQQMgR2NOwcKgmWBSQSYNIZIiXJBhFo X-IPAS-Result: AlgCAO89B1NKfVKrlGdsb2JhbABZg0GDWr02gREWDgEBAQEHCwsJEiqCJQEBBSMPAQUIARscAQEDDAYFCw0CAgUMCgsCAgkDAgECARERAQUBDgENBg0BBwEBF4dVAQMRBAEInw2MDFODDpUwChknDWSGeBEBAQQMgR2NOwcKgmWBSQSYNIZIiXJBhFo X-IronPort-AV: E=Sophos;i="4.97,518,1389740400"; d="scan'208";a="49938996" Received: from mail-we0-f171.google.com ([74.125.82.171]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 21 Feb 2014 12:56:49 +0100 Received: by mail-we0-f171.google.com with SMTP id u56so2440281wes.2 for ; Fri, 21 Feb 2014 03:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=72Sl9rcQPnJUYf7r4ekWtB/Urk1G8LpqeMbnP9tt96M=; b=Q2POBHwH/rEu7wSnOEVptLsRTR2uRqJkxAlnKhJhwx0PR7zY/1bDZ4MttaLLSS3lQs 7J1fyS311g8axHwugZ7Agbbn+67F2oTvU5houOhEKVihbceh/vXN490uhqosOEgu4jAZ 1bK9KVZZrFiu80HzIBJSh+xaOpsdyfA9EX1NRZ6kZ/9JPV3seiYdn07vLmdzQ18ESz8j bVCuRqGUwGRxgZ/xaNt/RxR6iD4zhAEHr9RD/e+aa/WcXNpoj2pFZ7B1WvsT45RkDMN5 FZmJGMti+d3Rmnwf5t0FtyZmOZvV/GqsdC9IuPnflrIEvcoNGhZVkT3QCXKv892aHjUf BKWg== X-Received: by 10.180.87.9 with SMTP id t9mr2786616wiz.36.1392983809208; Fri, 21 Feb 2014 03:56:49 -0800 (PST) Received: from [192.168.43.119] ([90.84.144.236]) by mx.google.com with ESMTPSA id h13sm16460755wjr.22.2014.02.21.03.56.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 03:56:48 -0800 (PST) Message-ID: <53073EFA.2020501@gmail.com> Date: Fri, 21 Feb 2014 12:56:42 +0100 From: =?UTF-8?B?QmVub8OudCBWYXVnb24=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Adrien Nader CC: caml-list@inria.fr References: <20140218185032.GA20593@notk.org> <5306330F.1020401@inria.fr> <20140221075326.GC7924@notk.org> In-Reply-To: <20140221075326.GC7924@notk.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] [RFC] Remaining changes for cross-compilation support in OCaml Hi, For cross-compilation, have you seen opam cross-compiler packages for win32 and win64: https://github.com/vouillon/opam-windows-repository, and for android: https://github.com/vouillon/opam-android-repository? These repositories also provide opam packages for some cross-compiled libraries, which is not simple because it requires both the host ocaml compilers and the cross-ones. Itmight be interesting to combineour efforts... As with your compiler, linking bytecode with -custom doesn't work with these compilers too, due to the same reason. Probably just a naive question: to solve this problem, don't you think it would be possible to write a piece of OCaml code replacing the call to dlopen()/dlsym() in the OCaml compiler, that manually reads the C libraries and list the exported symbolsat compile time without loading them? Benoît. Le 21/02/2014 08:53, Adrien Nader a écrit : > Hi Xavier, > > On Thu, Feb 20, 2014, Xavier Leroy wrote: >>> ****************************** 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. > Camlp4 was clearly the main component to require this but I have also > been wondering about ocamldoc and ocamldep which can break because of > new syntax. > > For now this requirements is probably the safe approach. Note that this > restriction only checks for x.y.z versions, not for the tags than can > come after 'z'; it made working with trunk too difficult. > > Also, as a packager, I prefer this. I find that the other approach makes > packaging more difficult. > >>> *** 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. > OK; I liked pmake and its descendants, partly because of their clean > syntax with true flow control and thought it could be left as a > possibility. Anyway, I will take that route. > >>> *** 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. > I believe you refer to configuring for host, populating boot and then > configuring again for target. It's something I hadn't thought of and > could work nicely. I need to experiment with this a bit and see how > things would work out. > >>> *** 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). > I wish everyone (at least everyone doing devlopment) would have a 64b > machine but it's not the case unfortunately. ='( > > This is not an area in the compiler I know much, if any, about. This can > most probably be worked on separately from the other patches; if someone > wants to contribute and can do the changes, it will be much > appreciated. :) > >>> *** 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. > I see no cross-platform solution either. However, I expect most people > to build natively before doing cross-compilation and that should catch > most link errors hopefully (that's a small consolation). >