From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 1BA7DBDDA for ; Sat, 27 Aug 2005 00:47:16 +0200 (CEST) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7QMlEws030208 for ; Sat, 27 Aug 2005 00:47:15 +0200 Received: from rosella (ppp27-60.lns1.syd6.internode.on.net [59.167.27.60]) by smtp3.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id j7QMl4wZ028509; Sat, 27 Aug 2005 08:17:05 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] crosscompile problem From: skaller To: weigelt@metux.de Cc: caml-list@yquem.inria.fr In-Reply-To: <20050826120042.GA9061@nibiru.local> References: <20050826120042.GA9061@nibiru.local> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+paX4J4870Hn4lRW4SNt" Date: Sat, 27 Aug 2005 08:47:03 +1000 Message-Id: <1125096423.25384.46.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Miltered: at concorde with ID 430F9BF2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 autoconf:01 config:01 stdout:01 osx:01 variants:01 numbering:01 compiler:01 gcc:01 ocaml:01 bytecode:01 compiler:01 wrote:01 sourceforge:01 X-Attachments: type="application/pgp-signature" name="signature.asc" X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 --=-+paX4J4870Hn4lRW4SNt Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-08-26 at 14:00 +0200, Enrico Weigelt wrote: > it seems that crosscompiling ocaml is currently impossible.=20 [] > Since almost all packages have to cope with this problem and > also widely used buildsystems like autoconf also have no clean > way of handling this, I suggest moving away this configuration > from individual packages to some central point - an global=20 > config database. Acceptance would require standardisation of some kind. > We query this database by simply calling some given commandline > with the variable name as parameter. The value is simply printed > out on stdout, without linefeed. > This can be easily solved by a tiny shellscript and some carefully > maintained text database. (see attachement) Not so easy. Briefly, I am porting Felix to full cross-compilation support right now. This includes supporting Windows and OSX, as well as all Unix variants. I have to distinguish FOUR separate platforms: * build machine -- where package source is built * host machine -- where developers run Felix * target machine -- where the generated code is compiled=20 * run machine -- where the compiled code is run BTW: please do not use the archaic term 'Ansi C'. Responsibility for C was taken over by ISO decades ago. References to the=20 ISO C Standard differ in numbering to Ansi-C. It is particularly strange to see non-American people using this terminology. You need to recognize that the 'sizes' are dependent on many factors including the compiler and options. For example gcc can be coaxed into generating 32 bit code on a 64 bit platform by using -m32 option. For Ocaml in general there will be 3 machines: build/host, target, and run platforms.=20 Note that using bytecode compiler, you can cross-compile .. It isn't clear that it is all that easy to 'cross-compile' native code, since it is not just a matter of emitting architecture dependent instructions -- it also depends on the availability of libraries, and assemblers and linkers with cross-compilation support, eg not everyone uses ELF object files. --=20 John Skaller --=-+paX4J4870Hn4lRW4SNt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDD5vmsRp8/9aGVGsRAjjCAJ4zV0FfUqpz5clCdFhixG3MSFVTtgCfUjru PmhtSJTzp0LcsSrH9vMKqeA= =nAdJ -----END PGP SIGNATURE----- --=-+paX4J4870Hn4lRW4SNt--