From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 97B7FBCB0 for ; Fri, 10 Jun 2005 00:51:45 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j59MpiPt014659 for ; Fri, 10 Jun 2005 00:51:44 +0200 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA26996 for ; Fri, 10 Jun 2005 00:51:44 +0200 (MET DST) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j59MpgLV008328 for ; Fri, 10 Jun 2005 00:51:43 +0200 Received: from Rosella (ppp35-43.lns1.syd2.internode.on.net [59.167.35.43]) by ash25e.internode.on.net (8.12.9/8.12.6) with ESMTP id j59Mpdxp020186; Fri, 10 Jun 2005 08:21:40 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Caml on intel-OSX From: John Skaller To: padiolea@irisa.fr Cc: james woodyatt , The Caml Trade In-Reply-To: <36973.131.254.50.45.1118334009.squirrel@mail.irisa.fr> References: <1118295206.7145.165.camel@rosella.wigram> <0908894eeba2802d8441ea3476c67c36@wetware.com> <1118330851.8693.10.camel@rosella.wigram> <36973.131.254.50.45.1118334009.squirrel@mail.irisa.fr> Content-Type: text/plain Date: Fri, 10 Jun 2005 08:51:40 +1000 Message-Id: <1118357500.8693.80.camel@rosella.wigram> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42A8C800.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 42A8C7FE.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 irisa:01 bytecode:01 bytecode:01 ocamlrun:01 hashtbl:01 bignums:01 ocaml:01 ocaml:01 compiler:01 osx:01 compiler:01 bug:01 glebe:01 ...:98 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: On Thu, 2005-06-09 at 18:20 +0200, padiolea@irisa.fr wrote: > > Lol! no, it is a simple question. Can I make a bytecode program > > and just ship it an expect it to run? No. So what else is required? > > I guess that if your bytecode program require some external libraries, > such as for instance if you do a "open Dbm" then you must > have too this library. > I think that ocamlrun only include code to handle the Pervasive > library. The code uses only (a) the standard library (Hashtbl and so on), (b) the Unix library, and (c) Bignums. Therefore the bytecode only requires support to be found in the standard distribution. I have a suspicion that one needs to '-custom' link somehow, to make a suitable single bytecode interpreter. The desire here is to *avoid* building Ocaml from source on the target platform, instead to use pre-built binaries, or, at worst, build these binaries from source, excluding the full Ocaml toolkit -- the compiler isn't required since the program is already compiled to bytecode. Both myself and my friend are trying to build the Felix system on diverse platforms, and make it available easily to potential users: this includes not only Unix like systems, but also Windows, Apple, and IBM platforms. At present, he has got his hands on an Intel/Mac platform for a very limited time, (at the actual release conference) previously we worked on an IBM PPC64/Linux platform, G4 and G5 OSX platforms, and I'm trying to make the system build on native Windows Win32 (XP) without Cygwin, using MSVC++ compiler and prebuilt Ocaml .. as well as trying to make both a Godi and Debian packages ... I wait with dread the release of 64 bit XP .. So we're looking at ways to get the system up and running on new and weird platforms with the minimum of fuss. Both for ourselves as developers, and for end users. Whilst I personally prefer the ocaml native code compiler, at present I can't use it on my AMD64 as there appears to be a code generation bug in it for that platform -- so I'm using bytecode even for core development, (and it's a real pain for the Debian packaging .. since the system autodetects the native code compiler and tries to use it even though it doesn't work: there is no opportunity to intervene manually in Debian autobuilds) So we're looking at ways to get the system up and running on new and weird platforms with the minimum of fuss. Both for ourselves as developers, and for end users. Solving this problem 'satisfactorily' seems harder than writing a compiler :) -- John Skaller, skaller at users.sf.net PO Box 401 Glebe, NSW 2037, Australia Ph:61-2-96600850 Download Felix here: http://felix.sf.net