Dropbear

rpath bites me again

Written by

dropbear

in

,
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

Comments

4 responses to “rpath bites me again”

  1. mirabilos Avatar
    mirabilos

    //foo is NOT the same as /foo.
    ///foo is the same as /foo, though.

    POSIX bites. And this is completely a
    user error: –libdir shouldn’t reference
    ${prefix} at all, if you specify –prefix
    already anyway.

    I still don’t understand why DT_RPATH is
    bad (for directories not in the standard
    search path), though. All examples I’ve
    seen in the threads so far are bugs in
    other software.

    Reply
    1. Craig Avatar
      Craig

      The problem was, long ago, that if you didn’t have ${prefix} in libdir then you couldn’t install the packages. It was a long time ago, but DESTDIR would not always work. I think it was something like DESTDIR was applied only to the front of $prefix, so if libdir was defined without $prefix, then DESTDIR would not be applied because it would not be prepended to $libdir, only $prefix. You’d get your binaries going into $DESTDIR/bin and your libraries to /usr/lib which would fail.

      I’m glad to see that’s been fixed. I’ve actually now just nailed the libdir and mandir without the $prefix so its clear.

      The RPATH being bad is more about distributions moving libraries around. For a private library not in the standard search path it is ok under certain circumstances. So if yourpackage has a binary myfoo which uses libraries in /usr/lib/foo/* and its all part of the same package then rpath is ok. The Debian wiki page has more specifics about it which the main post has a link to.

      Anyhow yes, I did the wrong thing though libtool should be more forgiving. It also has some side effects. Yes you should use /usr not //usr but does that mean the entire rpath handling should change because of this? I’d say it shouldn’t. Thanks for your comment though, it explains (though perhaps doesn’t excuse) why libtool did what it did.

      Reply
  2. Peter Eisentraut Avatar
    Peter Eisentraut

    Actually, libtool is not wrong on that. It is not guaranteed that //usr/lib/x8664-linux-gnu is the same as /usr/lib/x8664-linux-gnu. Here is the relevant bit from the standard: “A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slash characters may be interpreted in an implementation-defined manner, although more than two leading slash characters shall be treated as a single slash character.” I doubt libtool handles the last part, but in general you shouldn’t have extra leading slashes for this reason.

    Reply
    1. Craig Avatar
      Craig

      The leading slashes were not done on purpose but were a side-effect of how the thing was setup. I’m not sure which standard you’ve quoted, perhaps POSIX. If // is not / then what, for a standard ext3 filesystem, is it? There really is two problems here. The first is that // isn’t / and perhaps libtool is following the standards though it fails the ‘least surprise test’ here. The second problem is that –disable-rpath should disable rpath and it doesn’t.

      I agree, in general you shouldn’t have two leading slashes.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts