Description of problem: gobject-introspection in rawhide is ignoring LD_LIBRARY_PATH. As a result, it's impossible to set GI_TYPELIB_PATH + LD_LIBRARY_PATH in order to get 'make check' to work correctly (it'll try to use the globally installed <name>-gobject-1.0.so.0 instead of the one you've just built, resulting in weird crashes). Version-Release number of selected component (if applicable): gjs-1.33.3-2.fc18.x86_64 gobject-introspection-1.33.3-1.fc18.x86_64 How reproducible: 100% Steps to Reproduce: 1. 'make -C gobject check' in libguestfs 2. 3. Actual results: Weird errors like: JS ERROR: !!! Exception was: Error: Unsupported type void, deriving from fundamental void JS ERROR: !!! message = '"Unsupported type void, deriving from fundamental void"' JS ERROR: !!! fileName = '"./bindtests.js"' JS ERROR: !!! lineNumber = '27' JS ERROR: !!! stack = '"@./bindtests.js:27 If I uninstall the (global) libguestfs-gobject package then it works. Further investigation with strace shows that it's ignoring LD_LIBRARY_PATH but using GI_TYPELIB_PATH: $ grep 'libguestfs-gobject-1.0.so.0' /tmp/strace.log open("/usr/lib64/libguestfs-gobject-1.0.so.0", O_RDONLY|O_CLOEXEC) = 3 $ grep 'Guestfs.*\.typelib' /tmp/strace.log open("/home/rjones/d/libguestfs/gobject/Guestfs-1.0.typelib", O_RDONLY) = 4 Expected results: Don't ignore LD_LIBRARY_PATH. Additional info:
Created attachment 598409 [details] strace.log
Any news on this? It's a very annoying and obvious bug.
What's the shared-library entry in the .gir file? I suspect it's an absolute path?
$ grep shared-library ./gobject/Guestfs-1.0.gir shared-library="libguestfs-gobject-1.0.so.0"
First, is this a regression? In other words, did this ever successfully work, or is this a feature request? Now, libgirepository just calls g_module_open() which just in turn calls dlopen() which in turn is in libc, and will respect LD_LIBRARY_PATH. I can't think of something which would be unsetting that. Are you setting LD_LIBRARY_PATH yourself, or are you executing libtool wrappers? Given I don't see libtool in your strace, I'm guessing it's the former. Are you sure your LD_LIBRARY_PATH is actually right? Hmm. I wonder if this is happening because the gjs binary has an RPATH on /lib64. It doesn't seem to here on Fedora 17. But can you give me the output of: $ eu-readelf -a /usr/bin/gjs | grep RPATH ?
Yes, it is a regression. The exact same code works fine on F17. We are setting LD_LIBRARY_PATH ourselves in a small wrapper script we have called 'run[.in]': https://github.com/libguestfs/libguestfs/blob/84c897c93a794e4bdab37dfd505618de68bf145d/run.in There's no RPATH in gjs on either F17 or F18. For both: $ eu-readelf -a /usr/bin/gjs | grep RPATH [no output] $ chrpath -l /usr/bin/gjs /usr/bin/gjs: no rpath or runpath tag found. Wihch binary did you seen an RPATH in?
However, this is different ... F17: $ chrpath -l /usr/lib64/libgobject-2.0.so /usr/lib64/libgobject-2.0.so: no rpath or runpath tag found. F18: $ chrpath -l /usr/lib64/libgobject-2.0.so /usr/lib64/libgobject-2.0.so: RPATH=/usr/lib64
I bet I know what happened. This is kind of my fault: http://pkgs.fedoraproject.org/cgit/glib2.git/commit/?id=b388bdb3b02e45efdd1af3af9c89b1bc9300d9f2 Basically we used to use 'chrpath' to delete the RPATHs. While Matthias was doing glib releases, this worked because he uses Fedora. But I'm guessing that Ryan made the last GLib release from Ubuntu/Debian which doesn't have the patched libtool. I'll take care of re-adding the chrpath bits, since I guess we need to be defensive against tarballs made on whatever noun-linux forks.
OK I've verified that: (a) Removing the rpath from the library by hand fixes the problem. (b) For some reason, glib2-2.33.6-2.fc18.x86_64 is fine (no rpath in the library). There's no difference in the spec file, but as you say it might be because of a difference in how the upstream tarball was prepared. $ chrpath -l /usr/lib64/libgobject-2.0.so.0 /usr/lib64/libgobject-2.0.so.0: no rpath or runpath tag found. $ rpm -qf /usr/lib64/libgobject-2.0.so.0 glib2-2.33.6-2.fc18.x86_64
Testing http://pastebin.mozilla.org/1754150 now
Try http://koji.fedoraproject.org/koji/taskinfo?taskID=4385080 when it pops out, please?
Yes, that package works, and has no RPATH in it.