[Caml-list] Re: ELF i386 dynamic linking patch. was: License Conditions for OCaml

[malc <malc@pulsesoft.com>]

"Jeff Henrikson" <jehenrik@yahoo.com> 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