Re: ocaml compiled binaries and rpath
On Wed, Apr 16, 2003 at 11:14:03AM +0200, Sven Luther wrote:
[...]
> > > 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.
I then misunderstood your position, sorry :(
[...]
> > 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.
Exactly, upstream view is very different from ours. Note that Alexandre
Oliva is now paid by Red Hat, but I am not sure he changed his mind,
because he wants libtool to be portable and behave the same way everywhere.
[...]
> 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.
This was the exact subject of the thread in debian-devel in 1999/01.
Alexandre Oliva explicitly told he did not want to implement such a flag
in libtool, because it provides more harm than good in the general case.
IMO you have the right solution, but upstream might be reluctant to
implement it in this case too.
Denis
Reply to: