Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 02:32:55PM +0200, Claudio Sacerdoti Coen wrote:
> > > Well, those common function may be conversion function (that is
> > > function that make a caml value from some C type). I don't see how
> > > those function could be in any other place that stublib.
> >
> > Let see what Claudio has to say about this.
>
> Didier is perfectly right. You always need to "export" the conversion
> functions between caml and C values.
And you really cannot put them in a separate C library that is common to
both stub libs ?
> > The stublib, no problem, but what about the lib... symlink ?
>
> We are considering your proposal of putting the symlink in
> a /etc/ld.so.conf - aware directory. This seems very reasonable
> and would remove the rpath. Hmmmmmm
>
> > Ok, one solution would be to simply add /usr/lib/ocaml/3.06/stublibs to
> > /etc/ld.so.conf, or perhaps to say that the only authorized rpath in an
> > ocaml library package is the stublib dir ? This way, there is a good
> > reason for this, and we can teach lintian to override this.
>
> This would be another alternative solution. Hmmmm
All this is fine, but still does not cleanly solve the problem. Well it
solves this, but causes problem with some of the planes we have for the
ocaml package.
The problem is that :
1) only sonamed libraries can go in /usr/lib, at least that is what
the debian policy says.
2) imagine you have more than one version of the library around, or
two different ocaml runtime (ocaml-3.06 and ocaml-3.07 for example),
then you would have to choose which of these you will have installed
in the ld.so aware library or in the /etc/ld.so.conf file.
The idea of separating the common stuff would cause the same kind of
problem, unless you use propper so names, that is.
Finally, maybe all this shows that there is a propper usage of rpath
finally, and that the ocaml_packaging_policy should allow rpath for
these cases, and these cases only.
What do you think about this Denis ?
Friendly,
Sven Luther
Reply to: