Gir bindings are broken when compiling with MSVC
tschoonj opened this issue · comments
Experienced behavior
I am trying to add graphene to conda-forge, as this is a dependency of the recently released gtk4 (thanks for that by the way!). This is going well for Linux and macOS, but I run into trouble on Windows, where compilation occurs with MSVC. The library itself builds fine, but I am getting a stream of warnings when the gobject-introspection bindings are being built. They don't error out, but the resulting typelib file is useless.
I have seen this before, with Harfbuzz, and have asked @lazka to look into this. I think what Harfbuzz and graphene have in common is that both projects apply filters to transform the symbol names, so I guess that has something to do with it.
Expected behavior
Fully working gobject-introspection bindings
Steps to reproduce
Build graphene on Windows with the MSVC compiler, with introspection and graphene_types options on.
Operating system in use
Windows
SIMD implementation in use
Don't know.
I am attaching the relevant warnings and the crippled gir file.
Let me know if you need anything else and I will gladly provide you with it.
Hi @tschoonj,
As in harfbuzz/harfbuzz#2643 (comment), it would be helpful if you can post a minimal script that uses the Graphene bindings that route through G-I that worked on Linux (or even better) MSYS builds, but did not work on Visual Studio builds. The SIMD implementation will most likely not matter here.
With blessings, and cheers!
<record name="Box"
c:type="_graphene_box_t"
glib:type-name="GrapheneBox"
glib:get-type="graphene_box_get_type"
c:symbol-prefix="box">The c:type attribute contains the wrong type, but I have no idea why, given that the same script generates the appropriate type on Linux.
I spent some more time investigating this, and was surprised to see that the gobject-introspection files are generated properly when compiling with VS2019, but fail with VS2017. No clue why though, and the latest meson isn't showing me any gir command output anymore.
This is true for both Harfbuzz and Graphene by the way.
Hi,
As a test, I had the filter script bail out when we get a GrapheneBox type:
It turns out that the filter script received a _graphene_box_t as its input on Visual Studio 2015/2017 and graphene_box_t on Visual Studio 2019, so need to figure out why the input type is somehow messed up...
There are also error message not unlike the ones in #42.
Not too sure how g-ir-scanner gets its input to the filter script...
Hi,
I tried this a bit further, apparently whether or not we have the filter script there is a introspectable="0" meaning the GObject definitions was not picked up somehow, possibly due to how the preprocessor works.
The 2019 compiler as far as I can tell has a better preprocessor in terms of C99 compliance, so that could be why things worked in 2019 but not 2017 nor 2015, and g-ir-scanner relies on the preprocessor.
Hi,
I went a bit further, and surprisingly I was able to get the correct .gir file for Graphene on another system that is running Visual Studio 2015 (which had the wrong .gir file generated). So, I looked into things, and found that on this other system although the correct .gir file was generated on Visual Studio 2015, but in my Visual Studio 2013 build, for instance, I was getting the invalid .gir file like I had on the other system for Visual Studio 2015.
So, I decided to compare the CFlags between the generated Ninja build files for Visual Studio 2013 and 2015, and it turns out that the include paths for:
Visual Studio 2013 x64 (PKG_CONFIG_PATH=c:\vs12.0\x64\lib\pkgconfig, meaning the PREFIX would be at c:\vs12.0\x64)
-Isrc\graphene-1.0-0.dll.p
-Isrc
-I..\..\git_repos\graphene\src
-Iinclude
-I..\..\git_repos\graphene\include
-Ic:/vs12.0/X64/../include
-Ic:/vs12.0/X64/include
-Ic:/vs12.0/X64/../include/glib-2.0
-Ic:/vs12.0/X64/lib/glib-2.0/include
Visual Studio 2015 x64 (PKG_CONFIG_PATH=c:\vs14.0\x64\lib\pkgconfig, meaning the PREFIX would be at c:\vs14.0\x64)
-Isrc\graphene-1.0-0.dll.p
-Isrc
-I..\..\git_repos\graphene\src
-Iinclude
-I..\..\git_repos\graphene\include
-Ic:/vs14.0/X64/../include
-Ic:/vs14.0/X64/../include/glib-2.0
-Ic:/vs14.0/X64/lib/glib-2.0/include
(For both of these installations I had includedir=${prefix}/../include in the dependent GIRepository's, GLib's (and GObject;s) .pc files, so for instance -Ic:/vs12.0/x64/../include is what I wanted, but not -Ic:/vs12.0/x64/include)
It turns out that I had dangling headers in c:\vs12.0\x64\include, so I was able to get a valid .gir file by deleting the dangling directory c:\vs12.0\x64\include, and things proceeded normally.
It seems like pkg-config will try to set -I$(PREFIX)\include as one of the include paths it found if that directory exists, even if none of the dependent .pc files have includedir=${prefix}/include. So, you might want to check whether there are any dangling include paths in your compiler cflags for the various object files, and throw things in the dangling include paths away or move them somewhere else, and things should work. It seems that g-ir-scanner is quite sensitive to what include paths are given and/or set in the environment, and it would be beyond me to fix that in g-ir-scanner
Hope this helps.
With blessings, and cheers!
I guess there's nothing to be done, here.