GNOME Bugzilla – Bug 733857
rpath is being set on tracker libraries
Last modified: 2014-08-07 10:41:21 UTC
Atleast in tracker-1.0, and as far as I can tell tracker 1.1, the shared libraries end up with an RPATH set, this is generally frowned upon in debian/ubuntu and I believe similar in Fedora. I couldn't find anything in the build system explicitly setting this RPATH, so not sure where it is coming from, but it would be good to get rid of it, and it is probably blocking our attempts to get tacker into ubuntu Main unless we can provide a good reason that it is set. I don't actually know enough about autotools foo, to work out why it is being set though.
I did some checks on openSUSE, but could not find a library with an RPATH, but I COULD find some with a RUNPATH (which is similar, without the side effect of overriding LD_LIBRARY_PATH, so normally not a bad thing). Can you please let me know WHICH of your libs have an RPATH set and potentially guide to some build logs?
It affects all of the shared libraries and a couple of the private libraries (-data and -extract) I am seeing the same behaviour with our archive builds and local jhbuild, I also downloaded and checked some fedora binary packages and there also RPATH is set, perhaps openSuse is converting this to RUNPATH somehow during builds? Here is a buildlog https://launchpadlibrarian.net/180238343/buildlog_ubuntu-utopic-amd64.tracker_1.0.2-1ubuntu1_UPLOADING.txt.gz
oh just to add, on debian/ubuntu (due to multi-arch layout) it is RPATH /usr/lib/x86_64-linux-gnu/tracker-1.0 anywhere else it will be /usr/lib/tracker-1.0
So I have also got this bug in another private build system that I am helping a client work out. I wondered what the correct policy is here. I have also identified where this is happening. It seems anywhere where we use private libraries (installed to $prefix/lib/tracker-1.0/), so far this includes libtracker-data, libtracker-common and libtracker-extract. For those in Makefile.am, we use something like this: libtracker_commondir = $(libdir)/tracker-$(TRACKER_API_VERSION) We did it this way initially following the GLib/GTK+ approach, but upon a quick check just now, it looks like only run-time dlopen()ed / shared libraries are installed like this now, not private libraries. What's the right way to do this? I am happy to change the "*dir =" to something else for our private libraries - the question is, to what?
Created attachment 282122 [details] [review] build: link with --enable-new-dtags if available, this replaces the hardcoded RPATH with RUNPATH
Martyn, above patch will make tracker libraries use RUNPATH instead of RPATH, this is atleast acceptable (from a distro point of view) since RUNPATH doesn't override LD_LIBRARY_FLAGS. Maybe there is a better way to fix this, but not sure what that would be.
Comment on attachment 282122 [details] [review] build: link with --enable-new-dtags if available, this replaces the hardcoded RPATH with RUNPATH Please go ahead and commit this. In your commit message, please link to the bug report so we know why this was added. Thanks again :)
Attachment 282122 [details] pushed as b0ce65d - build: link with --enable-new-dtags if available, this replaces the hardcoded RPATH with RUNPATH