From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA19266 for caml-redistribution; Tue, 22 Feb 2000 11:53:58 +0100 (MET) 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 JAA32311 for ; Tue, 22 Feb 2000 09:10:07 +0100 (MET) Received: from dpt-info.u-strasbg.fr (dpt-info.u-strasbg.fr [130.79.6.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA03764; Tue, 22 Feb 2000 09:10:06 +0100 (MET) Received: from lambda.u-strasbg.fr (lambda.u-strasbg.fr [130.79.75.49]) by dpt-info.u-strasbg.fr (8.9.3/8.9.3) with ESMTP id JAA18684; Tue, 22 Feb 2000 09:10:04 +0100 Received: from luther by lambda.u-strasbg.fr with local (Exim 3.12 #1 (Debian)) id 12NARO-00057k-00; Tue, 22 Feb 2000 09:13:06 +0100 Date: Tue, 22 Feb 2000 09:13:06 +0100 From: Sven LUTHER To: Xavier Leroy Cc: Gerd.Stolpmann@darmstadt.netsurf.de, Claude Marche , caml-list@inria.fr Subject: Re: Portability of applications written in OCAML Message-ID: <20000222091306.A19683@dpt-info.u-strasbg.fr> Reply-To: luther@dpt-info.u-strasbg.fr Mail-Followup-To: Xavier Leroy , Gerd.Stolpmann@darmstadt.netsurf.de, Claude Marche , caml-list@inria.fr References: <14505.19990.196972.627775@sun-demons> <00021700444302.30469@ice> <20000218103603.51298@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20000218103603.51298@pauillac.inria.fr>; from Xavier.Leroy@inria.fr on Fri, Feb 18, 2000 at 10:36:03AM +0100 Sender: weis On Fri, Feb 18, 2000 at 10:36:03AM +0100, Xavier Leroy wrote: > Claude Marche asks: > > >One idea could be distributing bytecode: is it true the any bytecode > >can be executed on any architecture and OS as soon as the right > >ocamlrun is used? (Even under non unix OSs like Microsoft-Windows or > >Mac-OS?) > > For MacOS, there are some problems with end-of-line being represented > by different control characters in MacOS and in Unix and Windows. So, > newlines in program output are broken. > > For MacOS and Windows, there is also the fact that file path names are > represented differently. So, if your program manipulates file names, > even though the Filename module, the bytecode may not work well under > a different OS. > > I think the easiest way to distribute an OCaml application is as > sources, plus binaries for a couple of popular architectures > (typically, Linux/Intel and Windows). Novice users can pick the > binaries, and experienced users should have no problems installing > OCaml for compiling your application. > > Gerd Stolpmann wrote: > > My suggestion: Every modern operating system can link libraries dynamically. > > This is also possible for the parts of the OCaml libraries written in C > > which need to be available in the runtime system. > > Right, I have been considering dynamic loading of C libraries as an > alternative to -custom. This would allow, among other benefits, > dynamic loading of Caml libraries that contain some C code. Would that make -custom bytecode arch independent again ? how do you handle libraries with different exported symbols per arch ? > There are some portability issues with old or exotic versions of Unix, > but I think it can be made to work under, say, Linux, Solaris, > Digital/Tru64 Unix, and Windows. There are some issues still to be > resolved, however, such as how to build shared C libraries in a > portable fashion, perhaps by using the GNU libtool package. > > > - Only libraries needed for the application are loaded into memory; > > the memory footprints become much smaller > > Yes and no, because static linking under C is able to remove members > of the .a archive that are not referenced, while dynamic loading > typically loads everything. But memory footprint of code is not much > of an issue these days. Euh, ... is the member removal not done using the strip program ? stripping ocaml bytecode executable is a very bad idea, as can be seen when trying to strip ocamldebug for example. Notice that ocamlc, ocamlopt and ocaml don't seem to suffer from this problem. Friendly, Sven LUTHER