Binaries define rpath

[GoogleCodeExporter]

This information was taken from lintian, one of Debian's QA build tools:

W: libcherokee-server0: binary-or-shlib-defines-rpath
./usr/lib/cherokee/libplugin_cgi.so /usr/lib/cherokee
N:
N:   The binary or shared library sets RPATH. This overrides the normal
N:   library search path, possibly interfering with local policy and
N:   causing problems for multilib, among other issues.
N:   
N:   The only time a binary or shared library in a Debian package should
N:   set RPATH is if it is linked to private shared libraries in the same
N:   package. In that case, place those private shared libraries in
N:   /usr/lib/<package>. Libraries used by binaries in other packages
N:   should be placed in /lib or /usr/lib as appropriate, with a proper
N:   SONAME, in which case RPATH is unnecessary.
N:   
N:   To fix this problem, look for link lines like:
N:       gcc test.o -o test -Wl,--rpath,/usr/local/lib
N:   or
N:       gcc test.o -o test -R/usr/local/lib
N:   and remove the -Wl,--rpath or -R argument. You can also use the
N:   chrpath utility to remove the RPATH.
N:   
N:   Refer to http://wiki.debian.org/RpathIssue for details.
N:   
N:   Severity: normal; Certainty: certain

Talking with Álvaro, he mentions those lines are generated by the autotools
- I will try to fix this issue in the Debian builds by following the
instructions mentioned in the wiki page mentioned above, but it should
probably be avoided in the upstream code, to help all other distributions.

Original issue reported on code.google.com by gunnarwo...@gmail.com on 29 Nov 2008 at 10:13

[GoogleCodeExporter]

I hope these fixes do not intend to break *my* distro because Debian doesn't 
like rpath?

Original comment by ste...@konink.de on 29 Nov 2008 at 10:22

[GoogleCodeExporter]

Stefan, this is something unrelated to Debain, actually. The use of rpath is 
not recommended because of a 
number of issue it brings up; basically, something you'd want to get rid of.

BTW, at the end of the day, we all are in the same boat, try to remember it.  
I'm certain that, whenever Gunnar (or 
any other packager) reports an issue like this, it is for the best of both the 
project and the distribution. :-)

As I said, I'm going to take a look at the information on the wiki. Let's see 
what we can do about this rpath 
thingy!

Original comment by alobbs on 29 Nov 2008 at 10:44

[GoogleCodeExporter]

Wouldn't removing rpath imply that we add our package dir ld.so.conf, hence 
making
Cherokee unavailable to all users that do not have root rights?

Original comment by ste...@konink.de on 29 Nov 2008 at 10:54

[GoogleCodeExporter]

(+ win32)

Original comment by ste...@konink.de on 29 Nov 2008 at 10:55

[GoogleCodeExporter]

Win32 is one of the platforms that *must* be compiled without rpath.

In the case of Linux, you know the path where the binaries will reside. On 
Windows, though, you have no idea 
where the user will put them (For instance: c:\program files\cherokee, 
d:\cherokee, c:\archivos de 
programa\cherokee)?

I cannot think a single case where getting rid of rpath wouldn't be a desirable 
thing.
Stefan, do you think I am missing something?

Original comment by alobbs on 29 Nov 2008 at 11:11

[GoogleCodeExporter]

I'm sincerely wonder how we go to the libs directory without rpath on windows :{

Original comment by ste...@konink.de on 29 Nov 2008 at 11:20

[GoogleCodeExporter]

The wiki reads:

---
According to JeffCarr, automake versions bigger than 1.9 don't have this 
problem, probably by avoiding RPATH on Linux 
hosts per default. (can someone confirm this?)
---

Gunnar, do you know something about that?

Original comment by alobbs on 30 Nov 2008 at 11:14

[GoogleCodeExporter]

Original comment by alobbs on 1 Dec 2008 at 2:00

• Added labels: OpSys-Linux, Type-Defect

[GoogleCodeExporter]

Sorry for not replying earlier - Basically, the ball is in my hands now, and it 
took
me a couple of days to ask around - as I am basically clueless when it comes to
library building details. I'm going for the obvious first, but so far, I've had 
no
luck. I'll report as soon as I try at least the methods outlined in the quoted 
Wiki page.

Original comment by gunnarwo...@gmail.com on 2 Dec 2008 at 7:49

[GoogleCodeExporter]

I was able to fix this issue for me, but not in the best way possible for the 
project
- I did it by monkey-patching 'configure' at build time:

sed -i -r 's/(hardcode_into_libs=).*$/\1=no/' configure

I can confirm this does work (i.e. it avoids including the rpath calls in the
configure script, and Cherokee works correctly after generating the packages). 

I feel the solutions outlined in this section to be the most easy and reliable 
to
apply and keep ported. Hopefully, one of them can be integrated to the official 
tree
- meanwhile, I'll keep the differences in a patch in Debian.

Thanks again!
http://wiki.debian.org/RpathIssue#head-f706fd937a60813c58e095dbf75b0d92003237c6

Original comment by gunnarwo...@gmail.com on 2 Dec 2008 at 8:32

[GoogleCodeExporter]

FWIW, the generated patch is at:

http://git.debian.org/?p=collab-maint/cherokee.git;a=blob;f=debian/patches/fix_r
path;h=21a7aae7dd9f6d884ce3e4d036c67f2863faa206;hb=fcead783894be293fcbcc18b7e8b2
47e59df1377

Original comment by gunnarwo...@gmail.com on 2 Dec 2008 at 8:39

[GoogleCodeExporter]

Gunnar,
Have you tested whether the package actually work after applying the patch?

Original comment by alobbs on 2 Dec 2008 at 8:57

[GoogleCodeExporter]

Only casually - First, lintian no longer complains:

  0 gwolf@mosca[2]/tmp$ lintian -i cherokee_0.11.2-2_amd64.changes 
  0 gwolf@mosca[3]/tmp$

Of course, no complaints are not worth much consolation on a broken package ;-) 
So I
installed them in two steps, because of the pre-dependency. BTW, this needs to 
be
done only when manually installing via dpkg (and not via apt or such):

  0 gwolf@mosca[4]/tmp$ sudo dpkg -i
libcherokee-{base,client,config,server}0_0.11.2-2_amd64.changes; sudo dpkg -i
cherokee_0.11.2-2_amd64.deb 
  (...)
  0 gwolf@mosca[5]/tmp$ su
  Password: 
  0 root@mosca[1]/tmp# cherokee-admin 

  Login:
    User:              admin
    One-time Password: oeiVzo460p9ueZbD

  Cherokee Web Server 0.11.2 (Dec  2 2008): Listening on port 9090, TLS disabled,
  IPv6 disabled, using epoll, 1024 fds system limit, max. 505 connections,
  single thread

Seems to work. Entered the admin interface, successfully launched/killed the
server... Static web pages render correctly. So, yes, it seems to work. But, of
course, the more tests, the better.

Original comment by gunnarwo...@gmail.com on 2 Dec 2008 at 11:14

[GoogleCodeExporter]

That's fantastic! :-)

Original comment by alobbs on 3 Dec 2008 at 6:18

• Changed state: Fixed