Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] License Conditions for OCaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jeff Henrikson <jehenrik@y...>
Subject: [Caml-list] ELF i386 dynamic linking patch. was: License Conditions for OCaml
> > 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

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:  FAQ:
To unsubscribe, mail  Archives: