Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 10:24:28AM +0200, Denis Barbier wrote:
> 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.
Err, i said the upstream need for an rpath should be ignored, that is
that we can safely remove the rpath.
> 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.
Remember that the rpath is only about C stublibs, all the rest is
statically linked anyway. I guess even worse, the rpath is about C
libraries that the ocaml stub librarie use, not really about things we
build.
> IMO this is harmful. In this case, you must first uninstall the previous
> package, then build the new ones.
A, ok, but again, i don't think this applies to our case.
> 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.
So, instead of using the rpath, we should fill a bug against the library
in case it breaks our app, ok with me.
> 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?
Since all such checks is about libraries in standard places (/usr/lib
and /usr/X11R6/lib mostly), i think it is only a paranoid usage of rpath
by upstream because they don't have the chance to work on an integrated
distribution, and can make no guess about what will go where. Also, i
think it is usefull for linking with user installed libraries (installed
all over the place) when not wanting to add them in either
/etc/ld.so.conf or using LD_PRELOAD_LIB.
> 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.
I think it would be nice if upstream included a -norpath or something
such option which would allow us to create stublibs without rpath and be
used in debian packages. Third party packages would follow as usual.
> [...]
> > 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.
But e handle this with dependencies and conflicts and such.
In fact a well done ocaml library package can not be installed with an
ocaml that is using the old lib location.
Friendly,
Sven Luther
Reply to: