GNOME Bugzilla – Bug 659064
Folks introspection data doesn't reference non-devel libraries
Last modified: 2011-09-14 16:50:53 UTC
See e.g. [1] and [2] for a very similar Tracker issue. The problem here is the typelib references the .so file instead of .so.$LT_CURRENT, so when e.g. I run gnome-shell on a system without folks-devel installed (which provides libfolks.so), I get this error at startup; "Log level 16: Failed to load shared library 'libfolks.so' referenced by the typelib: libfolks.so: cannot open shared object file: No such file or directory" [ and then e.g. search in the shell throws funny exceptions because things are not being parsed correctly by the introspection system ] [1] https://bugzilla.gnome.org/show_bug.cgi?id=658588 [2] http://git.gnome.org/browse/tracker/commit/src/libtracker-sparql/Makefile.am?id=7edc4acc7e33f369616430edb63b0f060b9c3ecd
Created attachment 196512 [details] [review] build: don't make the typelib depend on devel shared object files Untested patch, but builds fine.
*** Bug 658860 has been marked as a duplicate of this bug. ***
Duplicate of bug #658002, which also has a patch. I think Raúl's is probably more correct, because libfolks.so.$(LT_CURRENT) is a symlink for me, linked to libfolks.so.foo.bar.baz. However, my libtools knowledge is weak, so I'll ask around for an opinion on both approaches. *** This bug has been marked as a duplicate of bug 658002 ***
Review of attachment 196512 [details] [review]: After talking to ebassi on IRC, he's confirmed that your approach is the right one, and that I don't know what I'm talking about. Please commit to master. :-)
Review of attachment 196512 [details] [review]: Sorry, I was wrong. libtool doesn't just append LT_CURRENT to the library name; it does some calculations involving LT_AGE as well. Comment added to bug #658002 about this.