GNOME Bugzilla – Bug 585116
GIR writer: add shared-library attribute support
Last modified: 2015-08-11 09:59:28 UTC
GIR namespaces need the shared-library attribute in order for typelib-based bindings to dynamically load the proper libraries when items from the namespace are used. The attribute value emitted by Vala is the value of the library flag from valac.
Created attachment 136126 [details] [review] GIR writer: add shared-library attribute support
Gio-2.0.gir as shipped by gobject introspection uses the full so name in the shared-library attribute, so I suspect that this patch is not quite correct.
This is how AvahiCore-0.6.gir in gir-repository works. Also, I've tested girs generated with this patch with both gjs and PyBank.
The patch will work as is, because gobject-introspection will call g_module_build_path on the value, which will add appropriate prefix and suffix for given platform (i.e. it will prepend lib and append .so on unix, but append .dll on windows). However, when the library has soversion at the end, g_module_build_path will not know about it and cannot append it. In that case the complete name must be used. I am not sure what is the correct way to give soversion to vala, but there does not seem to be any. When there is, the .gir writing must be updated to take it into account, but until there, is, this will do. Perhaps the way would be to specify the full name to the --library option, in which case this would still be correct.
Created attachment 162833 [details] [review] Write shared-library to GIR How about this? By default it will write shared-library="package", but you can override it by passing a value to a new --shared-library option.
Is this patch really needed? It has been discussed on IRC that the .so names can be passed to g-ir-compiler.
(In reply to comment #6) > Is this patch really needed? It has been discussed on IRC that the .so names > can be passed to g-ir-compiler. Calculating the right .so name to pass to g-ir-compiler is not a trivial task, so the code for it should either be in Vala or g-ir-compiler. See: http://git.gnome.org/browse/folks/commit/?id=554d96c18d4309b5e8169c68b8bb747502161a8e for an example of the code which is necessary.
As it's not a trivial task and highly depending on the platform (not sure that happens on Windows), and given this is something that could go in g-ir-compiler, I think it's not worth supporting this. Apart from compiling the typelib, what happens if a Foo.gir depends on folks that has no shared-library information? Can Foo.gir build anyway as long as folks includes a <package name="..."/> information? In other words, is shared-library sensible to the build process of dependent girs even if there's a package information?
*** Bug 642576 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > As it's not a trivial task and highly depending on the platform (not sure that > happens on Windows) GIR files are not meant to be machine independent. Put the shared-library that you need when you build the binary as well.
Shouldn't this be RESOLVED: WONTFIX?
(In reply to comment #11) > Shouldn't this be RESOLVED: WONTFIX? I think so. valac has no way to know what the shared library will be named because it's generally not the one creating it. It's not like we just have to guess whether to use *.so or *.dll... we have no way of knowing /anything/ about the name. Having the build system pass the shared library name to g-ir-compiler is the only reasonable thing to do, since it is the only one who has any hope of actually knowing this information.
Note that there are some bindings that do not use typelib files, like the Lua bindings. The general idea is that typelibs don't have any special information beyond what a GIR could give you. I think it makes sense to put shared-library in the namespace tag somehow.
AFAICT the only thing we could do is add an argument to valac which would allow the build system to specify it, which basically punts on the issue Phillip raised. That said, we should be writing the pkg-config name (which is what we get from --library) to the GIR in a <package/> tag. Lua should be using that to figure out which libraries to load... if that's the case, then the shared-library attribute is superfluous, and I see no reason to add it. Also complicating matters is that almost all Vala software uses Autotools' built-in support, which includes generated C in dist tarballs and doesn't require valac to be installed, so the GIR needs to be included as well. In this case, a shared-library attribute would contain information relevant to the person rolling the tarball, but could very well be incorrect for anyone actually trying to use it.
pkg-config isn't available in library form as far as I'm aware, and it seems like a stretch to make people run /usr/bin/pkg-config at runtime. It sounds like it might be a good idea, but I'm not sure. I'll ask Colin and people. The alternate solution is to generate a Foo-1.0.gir.in and then s/@SHARED_LIBRARY@/$(shared_library)/ in the autotools goo.
(In reply to comment #15) > pkg-config isn't available in library form as far as I'm aware, and it seems > like a stretch to make people run /usr/bin/pkg-config at runtime. It sounds > like it might be a good idea, but I'm not sure. I'll ask Colin and people. Ah, when you said Lua was using the GIR I was thinking that meant it was a compile time binding. Parsing GIRs at runtime seems unwise (slow). Even if there were a pkg-config library, pkg-config files are part of devel packages--I don't think it would be appropriate to require devel packages to be installed, although *.girs also seem to be part of the devel packages, so maybe it's not such a problem. > The alternate solution is to generate a Foo-1.0.gir.in and then > s/@SHARED_LIBRARY@/$(shared_library)/ in the autotools goo. Yeah, that's feasible, though fairly horrible.
In debhelper, dh_girepository looks for the "shared-library" attribute to automatically generate dependencies, so there is another reason to do something here. Or another workaround I have seen is to run g-ir-scanner on the generated c files.
valac has no way of knowing what the name of the shared library will be, often even with the help of the build system. GIRs are created when valac transforms Vala code to C, and that C is then distributed (at least that is how autotools' built-in Vala support works, which is what most Vala projects use). valac isn't typically invoked when compiling from release tarballs--it doesn't even have to be installed. There is no way to know what the name of the shared library is going to be when creating the tarball, but the GIR is generated when creating the tarball. This could all be resolved pretty easily by simply not distributing the generated C files and simply requiring valac when compiling release tarballs. That would actually fix some other issues as well (like conditional compilation). Then we could pass the correct shared library name to valac pretty easily (Travis posted a link to the commit in folks to detect it). IMHO what really needs to happen is for someone to fix autotools in a way that doesn't break backwards compatibility (maybe hiding the new behavior behind an option). I'd like to see a --shared-library flag (or whatever) added to valac in the mean time; if someone ever fixes autotools we could then pass the correct value there, and until then we could pass @SHARED_LIBRARY@ then replace that with the correct value (like Jasper suggested) once we actually know it. It's not elegant, but at least it should work. > Or another workaround I have seen is to run g-ir-scanner on the generated c > files. That's not going to end well. We don't generate G-I annotations in the C, and even if we did I don't think we could capture everything which we currently put in the GIR. You'll likely end up with a broken, leaky, crash-prone, terribly incomplete GIR.
I'm ok with adding the --shared-library option. Are the patches attached current? Also that happens on other platforms when .so is not the right name, like on windows?
(In reply to Luca Bruno from comment #19) > I'm ok with adding the --shared-library option. Are the patches attached > current? No, No idea if they still apply, but I think they should be changed so that if --shared-library isn't passed the GIR writer doesn't include that attribute instead of using a default value (of whatever was passed to --library). > Also that happens on other platforms when .so is not the right name, like on > windows? I'd say it's up to the build system to provide the correct value—that's a big part of the reason it's often not possible to know the value when valac is invoked. That said, last time I checked you don't actually need to include the extension for G-I to work since it uses g_module_open. Not sure things like Lua or Debian's scripts are that smart, though.
Created attachment 308559 [details] [review] Patch based on 2015 comments Here is a new patch. It adds a --shared-library option. If the option is specified, it will add `shared-library="NAME"` to the gir file, otherwise the `shared-library` attribute will be omitted. I've tested on a trivial .vala file with `../vala/compiler/valac --library=testlib -X -fPIC -X -shared -o libtest.so --gir=TestLib-1.0.gir --vapidir=../vala/vapi/ test.vala` and also omitting the --shared-library option. This patch also updates the man page. I'm not familiar with how that works, so hopefully I have done it correctly.
commit b51ed806a1964191ab3c351eb5d84ca0e6f8987a Author: David Lechner <david@lechnology.com> Date: Tue Aug 11 11:57:52 2015 +0200 Add --shared-library option for GIR files Fixes bug 585116 This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.