GNOME Bugzilla – Bug 667529
Add shared-library to vala generated .gir's
Last modified: 2013-01-10 08:45:45 UTC
For some reason, libgee uses this: Gee-0.8.typelib: Gee-0.8.gir @INTROSPECTION_COMPILER@ --shared-library=libgee-0.8 -o $@ $^ I've been looking around, and we usually don't use --shared-library directly when building introspection files. It could be because this is a vala library, though. The issue, though, is that in openSUSE, we use the shared library information from the typelib to extract a dependency on the library. So we need the full library (libgee-0.8.so.X) to have the correct information. Currently, we're patching libgee for that, but it's not really nice to do that downstream. So could we either drop the --shared-library argument completely (unless it's really needed, as opposed to most other libs) or could we get the library version in there too?
In libvirt-glib for example this is solved like this in Makefile.am: [...] --library=$(builddir)/libvirt-glib-1.0.la [...] This results as well in the correct Requires in the .typelib file.
Sorry; that invocation of --library actually needs to be done when creating the .gir file. But in case of libgee, the .gir file is shipped in the tarball instead of being generated on the fly during build. So please ignore comment #1.
(In reply to comment #2) > Sorry; that invocation of --library actually needs to be done when creating the > .gir file. But in case of libgee, the .gir file is shipped in the tarball > instead of being generated on the fly during build. So please ignore comment > #1. I don't use GIR extensively but the proper fix seems to be to strip lib from library: ---shared-library=FILENAME Specifies the shared library where the symbols in the typelib can be found. The name of the library should not contain the leading lib prefix nor the ending shared library suffix. Beside that: I don't know the code used by OpenSUSE but I am afraid that I cannot relay that .so is the suffix of libraries. For example it is false on native Windows[1] (and the thriving native Windows libgee+gir community would surly miss it ;) ). Could you elaborate? [1] By native I mean not cygwin or something similar.
Created attachment 205424 [details] [review] Use the .la file to find the right library That's why I wrote higher to use the .la file to do 'the right thing'. As the build system is relying on libtools, on all platforms we will have the .la files available and as such it always contains the right thing. The attached patch does just that.
(In reply to comment #4) > Created an attachment (id=205424) [details] [review] > Use the .la file to find the right library > > That's why I wrote higher to use the .la file to do 'the right thing'. > As the build system is relying on libtools, on all platforms we will have the > .la files available and as such it always contains the right thing. > > The attached patch does just that. I am still not convinced that this is the right way. It creates a mismatch between .typelib and .gir (which we had before but I don't think we should). I'm applying the patch as a temporary measure - possibly final result should be somehow integrated into valac/autotools to allow building .gir with correct shared-library set. PS. It seems that the --library in scanner is resolving the .la but not the --shared-library.
Comment on attachment 205424 [details] [review] Use the .la file to find the right library (As I have mentioned in previous comment introspection compiler doesn't resolve .la files)
This has actually been resolved in git / 0.9: http://git.gnome.org/browse/libgee/commit/?id=9e2e24f454d24e8247064116bfcaee0a5bd3a515 And the correctin http://git.gnome.org/browse/libgee/commit/?id=61a5947565d881c818bf57313927011675df1528 => Thus I close this bug as resolved...