Re: ocaml compiled binaries and rpath

[barbier@linuxfr.org (Denis Barbier)]

On Wed, Apr 16, 2003 at 08:11:17AM +0200, Sven Luther wrote:
> On Wed, Apr 16, 2003 at 12:27:59AM +0200, Denis Barbier wrote:
> > This was for the libc migration.
> > 
> > AFAICT OCaml situation is very different:
> >  * library location is not well established
> 
> Yes and no. We standardized the dll.so location in the stublibs
> directory, and most of the time this is enough. Users or rogue packages
> can still install stuff all over the place.

Sure, but let's wait for few years before telling it is well established ;)

> But i have the feeling that that the rpath is not really there to find
> the stublibs, which are found by the ocaml ld.conf file, but to find the
> C libraries these stublibs wrap, and this is why directories like
> /usr/lib and /usr/X11R6/lib are used. And especially you are not
> supposed to link a stublib from another.
> 
> So, my impression is that the rpath are usefull for homemade stublibs,

Yes, it can override system values.

> but can be safely ignored for debian packages.

I disagree, IMO lintian check is meaningful and should not be ignored.

Firstly you told in another mail that the planets executable is a native
code executable, and this is a key point, I forgot to mention it.
Previous example should call ocamlopt instead of ocamlc; one then
can run "objdump -p" on ELF executable to get RPATH informations.

[...]
> > I do not know of any viable solution to build packages because of
> > this problem, old libraries must be removed before building.
> > One might propose to Build-Conflicts against previous library versions,
> > but is it really what we want? ;)
> 
> No need, for debian package we currently have only one version of the
> packages installed, one version for a given ocaml version that is.

Maybe I was unclear, I will try with an example.

You have a source package foo_1-1 which builds libfoo_1-1 (a library) and
foo-bin_1-1 (containing programs built and linked against libfoo).
Both are installed on your system.
Now there is a new version, either 1-2 or 2-1.
If -rpath flag is used, foo-bin programs will be linked against *installed*
libraries, not the ones currently being built.
IMO this is harmful.  In this case, you must first uninstall the previous
package, then build the new ones.

Let me quote Alexandre Oliva from
 http://lists.debian.org/debian-devel/1999/debian-devel-199901/msg02260.html

  When a program is linked with a shared library, a contract is
  established between them stating that the library (or any newer but
  compatible version thereof, on systems that support library
  versioning) will supply the symbols that the program resolved from
  it, and the program will be able to find the library at that point.
  If you move the library and replace it with an incompatible one,
  you're breaking the contract and the versioning mechanism, so you
  can't blame the program for crashing, nor the tool that created the
  program.

This is the essence of -rpath, to provide a strong contract between pieces of
softwares.  But I am not sure that it is compatible with how we are building
packages (i.e. linking with libraries which are not installed into their
definitive location), this is why this lintian check should be looked at
carefully.  Is the executable built against the right libraries?

Of course there is an alternative, one could argue that -rpath does the
right thing and our packages should not contain more than one piece of
software.

[...]
> We don't really care about that, there is only one installed version of
> the library, and we don't move them around.
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Huh, are you kidding? ;)
I had the feeling that library location did change during last years.

Denis