rpath bites me again

Debian OpenLogo
Image via Wikipedia

It’s funny, in  bad way, when certain sorts of bugs come back to bite you.  People may remember the fun Debian had with rpath issues around in the late 90s where some binaries wanted to set the path of where their libraries were located.  After much contraversy the consensus was at least in Debian (with some specific exceptions) RPATH is bad and don’t use it.  I lived through that “fun” and remember hacking libtool or autoconf or some such file.

The horror of those times came back to haunt me today while working on procps 3.3.2 packages.  lintian was suddenly complaining that binary-or-shlib-defines-rpath for all my binaries.  I’ve not seen rpath set for many years and as I’m also part of the upstream and never saw it set there it took me a while to work out what was going on.

Certainly, my binaries were setting the RPATH, it wasn’t lintian getting the wrong idea.  You can see this with objdump myfile | grep RPATH. If you get a hit, you got RPATH set, an empty result means no RPATH. libtool was definitely setting the rpath, with

cc -Iproc -g -O2 -o $progdir/$file pmap.o  ./proc/.libs/libprocps.so 
 -Wl,-rpath -Wl,/home/csmall/debian/procps/procps/proc/.libs 
 -Wl,-rpath -Wl,//usr/lib/x86_64-linux-gnu

 

That’s not one rpath setting but two, for double insult. Configure flags such as –disable-rpath wouldn’t work. I flicked back to a pure upstream archive and there was no rpath there in either the compile flags or objdump. There was obviously some sort of side-effect going on.

The problem, after much testing, was in the debian/rules file:

        ./configure 
          --build=$(DEB_BUILD_GNU_TYPE) 
          --enable-watch8bit --enable-w-from 
          --prefix=/ 
          --mandir=$${prefix}/usr/share/man  
          --libdir=$${prefix}/usr/lib/$(DEB_HOST_MULTIARCH)

 

The problem is above, and all it was was a “/”. libtool does some checking to see if the library directory exists and if it doesn’t silently turns on rpath. It’s not smart enough to know that //usr/lib/x86_64-linux-gnu is the same as /usr/lib/x86_64-linux-gnu and so it enables rpath. Removing the slash before the usr fixed the problem.

I’d say this is bad behavour on libtools part. It should know that / is // or all the other alternative ways of specifying paths.  Hopefully this post will stop someone else wasting their time like I did.

 

Enhanced by Zemanta