Bug 840414 - gobject-introspection in rawhide ignores LD_LIBRARY_PATH at runtime
gobject-introspection in rawhide ignores LD_LIBRARY_PATH at runtime
Product: Fedora
Classification: Fedora
Component: gobject-introspection (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-07-16 06:06 EDT by Richard W.M. Jones
Modified: 2012-08-13 13:10 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-13 13:10:55 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
strace.log (306.13 KB, text/plain)
2012-07-16 06:10 EDT, Richard W.M. Jones
no flags Details

  None (edit)
Description Richard W.M. Jones 2012-07-16 06:06:06 EDT
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):


How reproducible:


Steps to Reproduce:
1. 'make -C gobject check' in libguestfs
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:
Comment 1 Richard W.M. Jones 2012-07-16 06:10:57 EDT
Created attachment 598409 [details]
Comment 2 Richard W.M. Jones 2012-08-11 13:05:07 EDT
Any news on this?  It's a very annoying and obvious bug.
Comment 3 Colin Walters 2012-08-13 10:04:19 EDT
What's the shared-library entry in the .gir file?  I suspect it's an absolute path?
Comment 4 Richard W.M. Jones 2012-08-13 10:40:55 EDT
$ grep shared-library ./gobject/Guestfs-1.0.gir
Comment 5 Colin Walters 2012-08-13 11:05:13 EDT
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

Comment 6 Richard W.M. Jones 2012-08-13 11:20:01 EDT
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]':


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?
Comment 7 Richard W.M. Jones 2012-08-13 11:22:38 EDT
However, this is different ...

$ chrpath -l /usr/lib64/libgobject-2.0.so
/usr/lib64/libgobject-2.0.so: no rpath or runpath tag found.

$ chrpath -l /usr/lib64/libgobject-2.0.so
/usr/lib64/libgobject-2.0.so: RPATH=/usr/lib64
Comment 8 Colin Walters 2012-08-13 11:30:31 EDT
I bet I know what happened.  This is kind of my fault:


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.
Comment 9 Richard W.M. Jones 2012-08-13 11:34:56 EDT
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
Comment 10 Colin Walters 2012-08-13 11:56:42 EDT
Testing http://pastebin.mozilla.org/1754150 now
Comment 11 Colin Walters 2012-08-13 12:07:53 EDT
Try http://koji.fedoraproject.org/koji/taskinfo?taskID=4385080 when it pops out, please?
Comment 12 Richard W.M. Jones 2012-08-13 12:31:51 EDT
Yes, that package works, and has no RPATH in it.

Note You need to log in before you can comment on or make changes to this bug.