From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA29204; Tue, 22 Oct 2002 19:14:35 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 TAA27291 for ; Tue, 22 Oct 2002 19:14:34 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g9MHEP524353; Tue, 22 Oct 2002 19:14:25 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA29592; Tue, 22 Oct 2002 19:14:24 +0200 (MET DST) Date: Tue, 22 Oct 2002 19:14:24 +0200 From: Xavier Leroy To: Sven Luther Cc: Yang Shouxun , caml-list@inria.fr Subject: Re: [Caml-list] on the -pack option Message-ID: <20021022191424.B28301@pauillac.inria.fr> References: <200210221333.36858.yangsx@fltrp.com> <20021022104215.A9456@pauillac.inria.fr> <20021022092103.GA1344@iliana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20021022092103.GA1344@iliana>; from luther@dpt-info.u-strasbg.fr on Tue, Oct 22, 2002 at 11:21:04AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Is there a particular reason why ocamlmklib does not support the pack > option ? Well, basically because I think it wouldn't make much sense. The job of ocamlmklib is to build a mixed C/Caml library, that is: - a ".cma" Caml library - a ".a" and/or ".so" C library - the necessary annotations in the ".cma" so that the C part is automatically linked. I feel that packing a set of Caml object files (.cmo) into substructures of a single Caml object file (which is what -pack does) is best done by a separate invocation of ocamlc -pack. That is, you can always do ocamlc -pack -o mylib.cmo a.cmo b.cmo c.cmo ocamlmklib -o mylib ... mylib.cmo > Also, i have the feeling that the correct way of distributing a bunch of > .cmo is to create a .cma, not to cram them together in a super .cmo > thanks to the pack option, i may be wrong about this though. > > The current documentation only gives an example of using the -pack > option to build .cmos, not to build a .cma. Maybe such an example could > be added, or at least a little notice about it ? I agre with Chris' reply. Maybe the docs should be clearer about this, but basically a .cma is a set of .cmo, while -pack builds a single .cmo from other .cmo. Nothing prevents you from packing cmo's into lib.cmo (ocamlc -pack -o lib.cmo ...), then building lib.cma containing only lib.cmo (ocamlc -a -o lib.cma lib.cmo). That might be useful if your lib also needs C code, as shown above. > [about not linking unused code] > BTW, if you pack the .cmos into a single .cmo and then put this one in a > .cma, you should get the same benefit as what you describe, isn't it ? Unfortunately not. The .cma contains only one .cmo, which is either not linked at all or linked in full. For the bytecode compiler, it could be possible to eliminate unused code with a finer grain. But for the native-code, we are severely constrained by what the Unix and Win32 linkers know how to do, and they can only eliminate whole object files, not parts of them. For some libraries, this isn't really a problem: by design, you'll generally use most of their modules. For other libraries (e.g. Baire :-) it's more problematic. There is a delicate trade-off here between selective linking and avoiding compilation unit namespace pollution. I can't say I'm completely happy about this, but I'm afraid this is the best we can do with the limited abilities of today's linkers. > BTW, advi build fails on ia64 Yes, your bug report is in the database and will be addressed in due time. - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners