After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791902 - Building using non-libtool (e.g., meson) on MinGW
Building using non-libtool (e.g., meson) on MinGW
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
unspecified
Other Windows
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-12-23 20:21 UTC by Zaki Mughal
Modified: 2018-01-23 03:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
scanner: Fix library lookup under MinGW without libtool (1.80 KB, patch)
2018-01-22 10:30 UTC, Christoph Reiter (lazka)
committed Details | Review

Description Zaki Mughal 2017-12-23 20:21:03 UTC
When I was using meson to build graphene with gobject-introspection support under MSYS2's MinGW64, I had to make sure that the built graphene DLL was available for the linker and for running the introspection executable.

To do so, I added the path to the built DLL to both the `LIBRARY_PATH` and `PATH` environment variables before running `g-ir-scanner`.

  - I added to the `LIBRARY_PATH` so that the DLL would be in the path returned by `gcc -print-search-dirs` <https://git.gnome.org/browse/gobject-introspection/tree/giscanner/ccompiler.py?h=1.55.0#n288>.

  - I added to the `PATH` so that Windows will be able to load the DLL when running the built introspection executable.

Those approaches are just hacks. It might be better to use the `-L` flags to add to the `libsearch` variable and later use that for the `PATH`.

Originally reported at <https://github.com/ebassi/graphene/issues/112>.

Related bug <https://bugzilla.gnome.org/show_bug.cgi?id=781525>.
Comment 1 Christoph Reiter (lazka) 2018-01-22 10:30:53 UTC
Created attachment 367204 [details] [review]
scanner: Fix library lookup under MinGW without libtool

When executing the scanner binary use the PATH/LIB env vars
also under MinGW, since LD_LIBRARY_PATH/rpath doesn't work there.

When resolving the library name from the import library look into
the user provided library paths first before falling back to the
default gcc search path.

This fixes the gir/typelib generation for meson under MSYS2.
Note that MSYS2 ships various patches, so this might not fix it
for all MinGW users.
Comment 2 Emmanuele Bassi (:ebassi) 2018-01-22 11:22:46 UTC
Review of attachment 367204 [details] [review]:

This looks good to me, but I'd really like to have a second pair of eyes on it, especially people building with MSVC instead of MSYS2.
Comment 3 Fan, Chun-wei 2018-01-22 15:37:18 UTC
Review of attachment 367204 [details] [review]:

Hi,

I think this seems ok to me as well, as this should not affect Visual Studio builds at all.

p.s. I also need help from someone to look at bug 702988, to fix a long-standing bug using the girepository DLL on x64 Windows that was built using Visual Studio at least.

With blessings, and cheers!
Comment 4 Christoph Reiter (lazka) 2018-01-22 18:00:57 UTC
Do you mean bug 702788 ? I've already reviewed that patch, so not much more I can do I think :)

Thanks for the reviews!
Comment 5 Christoph Reiter (lazka) 2018-01-22 23:37:54 UTC
I've built graphene as suggested in https://github.com/ebassi/graphene/issues/112 and everything seems to work fine.
Comment 6 Fan, Chun-wei 2018-01-23 03:01:46 UTC
Hi Christoph,

(In reply to Christoph Reiter (lazka) from comment #4)
> Do you mean bug 702788 ? I've already reviewed that patch, so not much more
> I can do I think :)

Yeah, I understand (and thanks!), and indeed it is bug 702788, sorry! :)

My post was basically a "ping" call, since 702788 was not looked at for a while, and I'd really like that bug to be fixed upstream, so that bindings can work much better on Visual Studio x64 builds.

With blessings, thank you!