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 PAA14876 for caml-redistribution@pauillac.inria.fr; Tue, 22 Feb 2000 15:01:07 +0100 (MET) Resent-Message-Id: <200002221401.PAA14876@pauillac.inria.fr> Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA09355 for ; Tue, 22 Feb 2000 10:21:19 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA17121; Tue, 22 Feb 2000 10:21:18 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA04326; Tue, 22 Feb 2000 10:21:16 +0100 (MET) Message-ID: <20000222102116.38250@pauillac.inria.fr> Date: Tue, 22 Feb 2000 10:21:16 +0100 From: Xavier Leroy To: Gerd.Stolpmann@darmstadt.netsurf.de, Claude Marche , caml-list@inria.fr Subject: Re: Portability of applications written in OCAML References: <14505.19990.196972.627775@sun-demons> <00021700444302.30469@ice> <20000218103603.51298@pauillac.inria.fr> <20000222091306.A19683@dpt-info.u-strasbg.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: <20000222091306.A19683@dpt-info.u-strasbg.fr>; from Sven LUTHER on Tue, Feb 22, 2000 at 09:13:06AM +0100 Resent-From: weis@pauillac.inria.fr Resent-Date: Tue, 22 Feb 2000 15:01:07 +0100 Resent-To: caml-redistribution@pauillac.inria.fr > Would that make -custom bytecode arch independent again ? That's the idea, yes. > how do you handle libraries with different exported symbols per arch ? Typically, when interfacing an existing C library with Caml, you have two libraries: the C library and a library containing the stub functions for communication with Caml. The latter must export the same stub functions on all platforms, indeed, but it can then adapt to variations in the underlying C library using #ifdefs and so on. > Euh, ... > is the member removal not done using the strip program ? Not at all. I was talking about the following feature of Unix linkers: when a ".a" library is statically linked, not all ".o" object files contained in the library are linked and put in the executable, but only those that define symbols actually referenced by the 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. Yes, all bytecode executables produced with the -custom option must not be stripped. This is even mentioned in the manual, I think. - Xavier Leroy