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 E99DABDDA for ; Sat, 27 Aug 2005 08:20:54 +0200 (CEST) Received: from metux.de (seven.metux.de [193.16.1.1]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j7R6KrZg004542 for ; Sat, 27 Aug 2005 08:20:54 +0200 Received: (from weigelt@localhost) by metux.de (8.12.10/8.12.10) id j7R6Krgs010067 for caml-list@yquem.inria.fr; Sat, 27 Aug 2005 08:20:53 +0200 Date: Sat, 27 Aug 2005 08:20:52 +0200 From: Enrico Weigelt To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] crosscompile problem Message-ID: <20050827062052.GA5364@nibiru.local> Reply-To: weigelt@metux.de References: <20050826120042.GA9061@nibiru.local> <1125096423.25384.46.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1125096423.25384.46.camel@localhost.localdomain> User-Agent: Mutt/1.4.1i X-Miltered: at concorde with ID 43100645.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 autoconf:01 config:01 osx:01 variants:01 namespaces:01 compiler:01 gcc:01 ocaml:01 bytecode:01 compiler:01 ...:98 ...:98 cellphone:98 wrote:01 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 * skaller wrote: > > 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 > > config database. > > Acceptance would require standardisation of some kind. Shouldn't be such a problem. We just have to found a separate group (outside of the caml project), which thinks carefully and makes some definitions ... > > 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 > * run machine -- where the compiled code is run Well, just a job for namespaces ... (build.*, host.*, ...) > BTW: please do not use the archaic term 'Ansi C'. Responsibility > for C was taken over by ISO decades ago. References to the Okay, s/ansi/iso/g; > 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. In this case you explicitly change the host platform, so it also requires proper adaption of the config-db. > For Ocaml in general there will be 3 machines: build/host, target, and > run platforms. > > Note that using bytecode compiler, you can cross-compile .. BTW: is the output of the ocaml-compiler platform dependent ? > 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. Well, I'm crosscompiling quite evrything. It normally works. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact@metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------