Re: ocaml compiled binaries and rpath
On Tue, Apr 15, 2003 at 07:02:16PM +0900, Junichi Uekawa wrote: > > > > Just ignore it or add a override. > > > > > > Any reason not to Build-Depend: chrpath, and do 'chrpath --delete' on > > > the result? > > > > Personnaly i don't know, i am no expert in rpath and don't fully > > understand the issues involved. > > > If you are adding an rpath to a non-default directory, there is a > reason for it; like /usr/lib/ocaml-whatever/ . > > However, adding rpath to /usr/lib is meaningless, because /usr/lib > is in the standard search path. > > So, for cases where rpath to /usr/lib is specified you should probably > look at removing the rpath. > For cases where there are specific reasons to do so (for example, > hiding ocaml related libraries in a subdirectory of /usr/lib/), > then rpath should be kept. Yes, i agree with that, the problem is that i am not really all that sure if this is the only thing involved. Anyway, i will be trying to look at this and understand it better before taking any action. These rpath may not be needed, but in any case, they don't hurt also, there is no urgency of removing them. Also, i think something else is going on in this specific case, and that the rpath is pulled in by the labltk stub library, i think. Anyway, i will not change anything about this before the ocaml mini-freeze is finished and the current ocaml packages have entered testing, which in turn depend on postgresql and the libvorbis mess. Also, i believe that if we are going to remove the rpath, the correct way is not to strip it, but to not add it to start with, and this means patching the ocaml build suite. And for this, i need to take the time to look at this specific issue, understand it well and so on. Friendly, Sven Luther
Re: ocaml compiled binaries and rpath
> > > Just ignore it or add a override. > > > > Any reason not to Build-Depend: chrpath, and do 'chrpath --delete' on > > the result? > > Personnaly i don't know, i am no expert in rpath and don't fully > understand the issues involved. If you are adding an rpath to a non-default directory, there is a reason for it; like /usr/lib/ocaml-whatever/ . However, adding rpath to /usr/lib is meaningless, because /usr/lib is in the standard search path. So, for cases where rpath to /usr/lib is specified you should probably look at removing the rpath. For cases where there are specific reasons to do so (for example, hiding ocaml related libraries in a subdirectory of /usr/lib/), then rpath should be kept. regards, junichi
Re: ocaml compiled binaries and rpath
On Mon, Apr 14, 2003 at 05:07:26PM -0600, Joel Baker wrote: > On Fri, Apr 11, 2003 at 11:11:17AM +0200, Sven Luther wrote: > > On Thu, Apr 10, 2003 at 10:56:34PM +0200, Martin Pitt wrote: > > > lintian says: > > > > > > W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets > > > /usr/lib:/usr/X11R6/lib > > > N: > > > N: The binary or shared library defines the `RPATH'. Usually this is a > > > N: bad thing. Most likely you will find a Makefile with a line like: > > > N: gcc test.o -o test -Wl,--rpath > > > N: or > > > N: gcc test.o -o test -R/usr/local/lib > > > N: Please contact debian-devel@lists.debian.org if you have questions > > > N: about this. > > > > Just ignore it or add a override. > > Any reason not to Build-Depend: chrpath, and do 'chrpath --delete' on > the result? Personnaly i don't know, i am no expert in rpath and don't fully understand the issues involved. But upstream strongly advice against doing such things. Here is a mail about this on the debian-ocaml-maint list, but i have not had time to read it fully and understand it myself. http://lists.debian.org/debian-ocaml-maint/2003/debian-ocaml-maint-200304/msg00026.html Claudio Sacerdoti Coen, who works with Stefano i understand, have issues with inter-dependent (ocaml) library packages and such, and encountered this kind of problems. Also remember, that this is about ocaml, not just a bunch of C libraries or executables, and other consideration may apply. Friendly, Sven Luther
Re: ocaml compiled binaries and rpath
On Fri, Apr 11, 2003 at 11:11:17AM +0200, Sven Luther wrote: > On Thu, Apr 10, 2003 at 10:56:34PM +0200, Martin Pitt wrote: > > lintian says: > > > > W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets > > /usr/lib:/usr/X11R6/lib > > N: > > N: The binary or shared library defines the `RPATH'. Usually this is a > > N: bad thing. Most likely you will find a Makefile with a line like: > > N: gcc test.o -o test -Wl,--rpath > > N: or > > N: gcc test.o -o test -R/usr/local/lib > > N: Please contact debian-devel@lists.debian.org if you have questions > > N: about this. > > Just ignore it or add a override. Any reason not to Build-Depend: chrpath, and do 'chrpath --delete' on the result? -- Joel Baker <[EMAIL PROTECTED]> pgpoDdFlmOlfG.pgp Description: PGP signature
Re: ocaml compiled binaries and rpath
On Thu, Apr 10, 2003 at 10:56:34PM +0200, Martin Pitt wrote: > Hi! > > I'm just packaging planets (#187988) which is written in ML and > compiled with ocaml. The problem is that the ocaml linker uses the > rpath feature (i. e. hardcoded libary paths). Yes, it does ... > It seems to be against Debian policy to use rpath; on the other hand, > the ocaml linker does not seem to allow disabling it (at least the > documentation says nothing about this issue). Well, see the huge flamewars about this on debian-mentors some time back. It didn't resulted in any conclusive result though. > lintian says: > > W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets > /usr/lib:/usr/X11R6/lib > N: > N: The binary or shared library defines the `RPATH'. Usually this is a > N: bad thing. Most likely you will find a Makefile with a line like: > N: gcc test.o -o test -Wl,--rpath > N: or > N: gcc test.o -o test -R/usr/local/lib > N: Please contact debian-devel@lists.debian.org if you have questions > N: about this. Just ignore it or add a override. > Does anybody know whether it's possible to avoid that? If not, it is > just a warning, so how bad it would be just to ignore it? Well, as ocaml packager, i would vote for letting it like that, as said, there are argument for both solutions, and i prefer to let things like upstream does it (be it only for compatibility with other non-debian related packages). That said, i thought that this kind of problem only occured with library packages using C binding stub libs. I will try to have a look at your package this evening, if you give me a pointer to it. That said : 1) have you read the ocaml packaging policy in /usr/share/doc/ocaml ? 2) There is a debian-ocaml-maint mailing list that is maybe more suited to discusing things related to packaging ocaml stuff, and i will CC this mail there, where you may want to subscribe if you are going to maintain ocaml related stuff. Friendly, Sven Luther
Re: ocaml compiled binaries and rpath
Martin Pitt <[EMAIL PROTECTED]> writes: > Hi! > > I'm just packaging planets (#187988) which is written in ML and > compiled with ocaml. The problem is that the ocaml linker uses the > rpath feature (i. e. hardcoded libary paths). I don't know the answer, but you should ask on debian-ocaml-maint@lists.debian.org, where you will find several debian maintainer that have packaged ocaml program [...] -- Rémi Vanicat [EMAIL PROTECTED] http://dept-info.labri.u-bordeaux.fr/~vanicat
ocaml compiled binaries and rpath
Hi! I'm just packaging planets (#187988) which is written in ML and compiled with ocaml. The problem is that the ocaml linker uses the rpath feature (i. e. hardcoded libary paths). It seems to be against Debian policy to use rpath; on the other hand, the ocaml linker does not seem to allow disabling it (at least the documentation says nothing about this issue). lintian says: W: planets: binary-or-shlib-defines-rpath ./usr/bin/planets /usr/lib:/usr/X11R6/lib N: N: The binary or shared library defines the `RPATH'. Usually this is a N: bad thing. Most likely you will find a Makefile with a line like: N: gcc test.o -o test -Wl,--rpath N: or N: gcc test.o -o test -R/usr/local/lib N: Please contact debian-devel@lists.debian.org if you have questions N: about this. Does anybody know whether it's possible to avoid that? If not, it is just a warning, so how bad it would be just to ignore it? Thanks a lot and have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED] Verteidigen Sie Ihre Freiheit und Ihre Rechte! Stoppt TCPA! Defend your freedom and your rights! Stop TCPA! http://www.notcpa.org pgpky5ki85gpJ.pgp Description: PGP signature
