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
