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 BAA29609; Sat, 10 Nov 2001 01:33:28 +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 BAA29658 for ; Sat, 10 Nov 2001 01:33:19 +0100 (MET) Received: from comtv.ru (mail.comtv.ru [217.10.32.4]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAA0XIn00682 for ; Sat, 10 Nov 2001 01:33:18 +0100 (MET) Received: from [10.2.64.72] (HELO oyster2) by comtv.ru (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1126862; Sat, 10 Nov 2001 03:33:08 +0300 Date: Sat, 10 Nov 2001 03:32:56 +0300 (MSK) From: malc X-Sender: malc@oyster To: Jeff Henrikson cc: Patrick M Doane , Will Benton , caml-list@inria.fr Subject: [Caml-list] Re: ELF i386 dynamic linking patch. was: License Conditions for OCaml In-Reply-To: <002e01c1692d$3f64cce0$0b01a8c0@mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk "Jeff Henrikson" writes: > > > 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 I consider it low priority for now. More interested to add unloading support for native compiled modules first. > 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. I dont know, i dont expect any problems here. But then again, havent looked closely at this. > 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? .mli doesnt give you this information, .cmx does. > 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! ;-) Well, i posted very sketchy first patch here, to collect comments, feature requests and so on. I guess you have seen how miserably i failed. I _really_ dont want to set standards on my own, but since almost nobody is interested im forced to implement things the way they suit me. > 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) If i'm reading apache log's correctly, there where 12 downloads of 1_shared.patch and 8 of 2_shared.patch. Overwhelming success. Sigh. Plus Xavier expressed team's disinterest in native dynamic linking (at least in forseeable feature) On the bright side Fabrice Le Fessant put it into CDK, on the down side, after Xaviers message about CDK and patches, he decided to remove them all. If he will go for optional patched compiler, it will screw shared patch because of .cmx .cmxa incompatibilities. And i bet not many possible CDK users will tollerate two(or more) multimegabyte trees. As for windows port, id happily provide any support i can. However i forsee many obstacles. Windows's PE isnt really as feature packed as ELF, there will be all sorts of visibility, scope etc problems. (Not that it cant be done or anything ;) P.S. Answering this message was a huge pain in the ass, i had to visit XEmacs to fight this horrible mess Outlook produced. Maybe you can fix that? -- mailto:malc@pulsesoft.com ------------------- 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