OCaml and static linking (was old thread: Re: [Fedora-packaging] Issues with Ocaml and Static Linking)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Toshio Kuratomi wrote:
On Sun, 2007-04-15 at 23:53 +1200, Nigel Jones wrote:
Nigel Jones wrote:
> Hi everyone,
> > While putting in a couple of packages for Extras Review I've stumbled
> into a couple of issues regarding how Ocaml links libraries and how the
> Fedora Packaging Guidelines are set.
> > My packages in question are:
> ocamlSDL (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235804)
> camlimages (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235805)
> freetennis (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235815)
> > Basically, ocamlSDL and camlimages produce two sets of libraries (a set
> of dynamic libraries, and another set for development etc), sadly when
> other packages like freetennis build, they staticly link to libraries
> such as camlimages/ocamlSDL.
> > I found it semi-suspect when I built freetennis, and hence why I asked
> on bugzilla when I posted the three packages for review, however I did
> some more questioning today and after a quick IRC discussion in #ocaml
> was told:
> > 12/04 13:39 < G> hmmm, .a .cma and .cmxa are all static ocaml libraries
> right?
> 12/04 13:44 < Smerdyakov> Those are the two library extensions, yes.
> 12/04 13:44 < Smerdyakov> Native code OCaml doesn't support dynamic loading.
> 12/04 13:44 < Smerdyakov> I expect that bytecode uses the same files for
>                           dynamic loading as static loading.
> > Looking at my installed files on my laptop, lablgl, lablgtk and labltk
> (as well as the main ocaml package) store .a, .cma and .cmxa files in
> /usr/lib/ocaml (and subfolders).
> > As I'm only new to Fedora packaging, could someone please advise on
> where I should from here on the matter and what the position of FESCO is
> on Ocaml static libraries, and where I should go from here.
> > Thanks, > > Nigel Jones

I'm just wondering if anyone has any thoughts on this issue.

I've talked to some more people in #ocaml (Freenode), who suggested that
 I try a patch by the name of 'scaml' which is a year or two old (and
although can be manually applied to the ocaml source, it does not work
(problems with assembly which I've not comfortable meddling with).

We'd actually need to downgrade to 3.07 which was removed from Fedora in
 Feb 05 to get the patch working to satisfy the need for dynamic loading
which I'm sure would upset a few people.

Upstream already have a bug opened stating that they need to fix the
issue but they have never updated it, or assigned it to anyone.

So my main question is "where to from here?"

I think, if the ocaml compiler doesn't support dynamic libraries, static
linking would be acceptable.  This doesn't mean that we shouldn't press
upstream to add dynamic linking (and convert all our packages when that
becomes available) just an acknowledgment that fixing the limitation has
to be done upstream  (it could be done by someone within Fedora but the
fix needs to go upstream).

This is similar to allowing C libraries in even if they only build
statically.

If I'm not understanding precisely what the limitation is, feel free to
clarify.

There are two issues here: (a) Having OCaml binaries link dynamically instead of statically to OCaml libraries. (b) Writing a dynamic library in OCaml, and having it used by programs written in other languages, particularly C.

I suspect it's unlikely that upstream will do (a), ever. There's a technical issue. OCaml really doesn't have a concept of an ABI. It does a kind of whole-program optimisation where even changes to the internal implementation of a library can affect the resulting binary. Moreover even if you "fixed" that, any change whatsoever to the library's signature or the version of compiler it was built with (even bugfix releases which have the same version number) will make the library incompatible.

You might also find this entertaining:

http://caml.inria.fr/pub/ml-archives/caml-list/2004/05/775714fbf05c17e0cbf5c365d6671704.en.html

Another issue which Xavier doesn't mention is the ability to fix a security bug in a shared library, and not require all dependent applications be recompiled. Well, there aren't many (any?) widely used OCaml libraries, and there aren't a lot of binaries which would need to be recompiled either. But it could be a problem for OCaml world domination plans.

As for (b), the ability to write libraries in a sane language and have them called through a C API: This almost works. Well, it works well on i386, but there are some problems on x86-64. I'm looking forward to having this. It needs some tools to make it work well - it would be nice to have the C header files and the complex Makefile fragments to get it to work generated automatically.

Rich.

--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux