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 PAA15498; Fri, 9 Nov 2001 15:32:02 +0100 (MET) 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 PAA15554 for ; Fri, 9 Nov 2001 15:32:01 +0100 (MET) Received: from c007.snv.cp.net (c007-h012.c007.snv.cp.net [209.228.33.219]) by concorde.inria.fr (8.11.1/8.10.0) with SMTP id fA9EW0n12651 for ; Fri, 9 Nov 2001 15:32:00 +0100 (MET) Received: (cpmta 15682 invoked from network); 9 Nov 2001 06:31:58 -0800 Received: from 65.187.194.217 (HELO vaiobambino) by smtp.directvinternet.com (209.228.33.219) with SMTP; 9 Nov 2001 06:31:58 -0800 X-Sent: 9 Nov 2001 14:31:58 GMT From: "Jeff Henrikson" To: "malc" , "Patrick M Doane" Cc: "Will Benton" , Subject: [Caml-list] ELF i386 dynamic linking patch. was: License Conditions for OCaml Date: Fri, 9 Nov 2001 09:46:00 -0500 Message-ID: <002e01c1692d$3f64cce0$0b01a8c0@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > > OCaml doesn't provide support for shared libraries (although 3.03 does > > provide some dynamic loading capabilities for bytecode only). So we > > need to consider the portions of the license that apply for static > > linking. The LGPL provides some rather contradictory statements in section > > 6 regarding that: > While this is true for stock ocaml, there is a patch that adds shared > linking support to 3.03Alpha, with limited scope though - i386 ELF only. > (shameless plug) You can find it here http://algol.prosalg.no/~malc/scaml Yes, but those pesky gensym integers lying around prevent exactly this thing. That is, if I write a library, compile to an .so/.cmxa pair, and link to it, all is apparently well in the world. Then if I try to change the implementation of the library but leave the interfaces alone, I find out all the symbol names will change randomly, eg myFunction243 to myFunction247 Fixing this may be as simple as removing a %s from the source. I don't know, as I didn't dig that deep. I also have a suspicion that entry points are sometimes not unique. I periodically hear things about multiple optimized entry points and I don't know if that affects their symbol names. I would presume it would, which would be another screw case to work on. The question is that if you provide an .mli, are multiple entry points ever generated. Actually, the real question is a little more strict: given an .mli file, are the symbols generated well-defined (except for the arbitrary integer), and will they still be unique if the integer is deleted? Does any kind guru care to comment? Though you aren't defining a calling convention or symbol naming scheme from scratch, you are still, in a sense, defininig a binary interface here. IMHO extreme paranoia is warranted! ;-) BTW, if you can address these concerns to my satisfaction, (And I wish other people were commenting on this. The list was strangely silent when you posted this patch- Am I the only one thinking this is extremely important?) I'm happy to port it to the windows dynamic linker. I already did this for another linking library whose limitations I don't like too much any more. (dlopen) Jeff Henrikson ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr