Thank you for your work, it is a big help for cross compiling for windows !
I cannot compile the afm-mingw-w64-gobject-introspection project.
It fails with this error message :
```
env PATH=".libs:/usr/i686-w64-mingw32/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" /usr/bin/env WINEARCH=win32 WINEPREFIX=/opt/afm-mingw-w64-gobject-introspection/src/win32 DISPLAY= /usr/bin/wine ./g-ir-compiler.exe --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92 --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir --includedir=. --includedir=. --includedir=. /opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir/libxml2-2.0.gir -o gir/libxml2-2.0.typelib
Invalid GType function: 'g_date_get_type'
Failed to find symbol 'g_date_get_type'
Command '['/usr/bin/env', 'WINEARCH=win32', 'WINEPREFIX=/opt/afm-mingw-w64-gobject-introspection/src/win32', 'DISPLAY=', '/usr/bin/wine', '/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92-build-i686-w64-mingw32/tmp-introspectZwwq8C/GLib-2.0.exe', '--introspect-dump=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92-build-i686-w64-mingw32/tmp-introspectZwwq8C/functions.txt,/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92-build-i686-w64-mingw32/tmp-introspectZwwq8C/dump.xml']' returned non-zero exit status 1
env PATH=".libs:/usr/i686-w64-mingw32/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" /usr/bin/env WINEARCH=win32 WINEPREFIX=/opt/afm-mingw-w64-gobject-introspection/src/win32 DISPLAY= /usr/bin/wine ./g-ir-compiler.exe --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92 --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir --includedir=. --includedir=. --includedir=. /opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir/xft-2.0.gir -o gir/xft-2.0.typelib
env PATH=".libs:/usr/i686-w64-mingw32/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" /usr/bin/env WINEARCH=win32 WINEPREFIX=/opt/afm-mingw-w64-gobject-introspection/src/win32 DISPLAY= /usr/bin/wine ./g-ir-compiler.exe --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92 --includedir=/opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir --includedir=. --includedir=. --includedir=. /opt/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.43.92/gir/xlib-2.0.gir -o gir/xlib-2.0.typelib
Makefile:3430: recipe for target 'GLib-2.0.gir' failed
make[2]: *** [GLib-2.0.gir] Error 1
```
fedora-mingw-w64-glib2 has been successfully installed before.
Do you have any clue how to fix this issue ?
Thank you very much !
Right now I am just in the middle of updating the whole toolchain to keep it in sync with fedora. I postponed it to avoid the new GTK+3 dependencies. I plan to finish it on this week end, so please hold on.
`gobject-introspection` has been already updated to HEAD. I hope the new patches will be accepted upstream (it has been a nightmare to update, again).
Thanks for your answer. Good news you're working on an update !
In between do you have an idea why the gobject-introspection build cannot find 'g_date_get_type' whereas it is defined in the glib package ?
Maybe related: I had similar problems while building pango (same error with different symbol). I had to apply `0002-msvc-is-impotent-but-not.mingw.patch` to solve.
Thanks for the tip but I don't know how to apply a similar patch to gobject-introspection. There is no *.def file in this package. I tried with version 1.43.3 and 1.43.92.
And do you know if trying to build a package coming from msys2 (https://github.com/Alexpux/MINGW-packages/tree/918edcd0d8c20f13def4e12915c63e8b495a7f21/mingw-w64-gobject-introspection) may work in your build environment ?
I finally got the package ! I think I got an issue with some dependency built without the right flags (..._AFM_...FLAGS).
I rebuilt everything with these flags and the gobject-introspection build is now OK.
Tough job ... Thank you again for your work and for the help !
Is it OK to use now the version you just pushed ? Or is it still a work in progress ?
Did you try to use python3 with gobject-introspection ? Is it possible ?
I just compiled the whole GTK+2/3 toolchain (with gobject-introspection and [lgi](https://github.com/pavouk/lgi) bindings) without issues, so it should be fine. I just tried a couple of applications with wine though.
GObject introspection build still uses python2. I do not plan to spend time to test python 3: it does not bring me any advantage.
Based on your work I manage to get it work with python 3.
The result is available here as a docker image : https://hub.docker.com/r/jcnoir/build-win32-gi/
Sorry to re-open an old thread but I pulled the last update from your project and I got the same error (Failed to find symbol 'g_date_get_type).
I tried to rebuild everything from scratch but it still complains.
I see that you made a change " buildall: fix compilation flag overriding ". I did not understand this update: you replace export CFLAGS=AFM_CFLAGS with export CFLAGS=$AFM_CFLAGS but I do not see where you set the AFM_CFLAGS value. May you help me to understand the issue ?
AFM is the prefix for this project: AUR Fedora MingW. Before the building loop, I have this snippet:
# Avoid using standard flags: too easy to rebuild everything with the
# wrong flags. Instead allow overriding via AFM_... custom variables.
export CFLAGS=$AFM_CFLAGS
export CPPFLAGS=$AFM_CPPFLAGS
export LDFLAGS=$AFM_LDFLAGS
export CXXFLAGS=$AFM_CXXFLAGS
This usually unsets `CFLAGS` and friends, to avoid clashes with compiler directives intended to be used by the host (e.g. you could have `CFLAGS` set to `-O2 -march=broadwell` because you want optimized local builds, but you cannot use those flags while cross-compiling).
Anyway I left a way to pass custom flags if you really want to, e.g.:
env AFM_CFLAGS="-O2 -Wall" AFM_CPPFLAGS=$AFM_CFLAGS ./build-all
It is worth noting that maybe those flags are completely useless and `makepkg` uses the ones found in `/etc/makepkg.conf` instead. Actually I have these settings there:
CPPFLAGS=
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong"
CXXFLAGS="-march=x86-64 -mtune=generic -O1 -pipe -fstack-protector-strong"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
Let me know if this solves the problem.
@jcnoir I just reworked the whole system to be environment independent.
Now the 32 and 64 bits toolchains are separated. Furthermore, they use a custom `makepkg.conf` for changing their flags.
I compiled both toolchains from ground without issues. Please refer to the [updated documentation](https://github.com/ntd/aur-fedora-mingw#how-to-use) for instructions.
Let me know if you still have problems.
This looks nice ! I will try it right now ... because I still got issues with the introspection pkg.
I will let you know ...
Thank you again for this work !
I still get the same error...
I read the updated documentation and use the default makepkg.common.conf. I reproduce your folders (/home/nicola/workdir/aur-fedora-mingw/aur).
I rebuild from scratch in a docker container.
I will try starting from the current arch base docker image.
> I will try starting from the current arch base docker image.
If your image is old enough, it would explain the problem.
gobject-introspection is compiled twice: the first time natively and the second time cross-compiled. The host glib and the build glib must match as much as possible. The host glib is 2.53.2, i.e. archlinux current.
Thanks for your advice.
I still got the issue in Docker.
I tried outside of Docker in a Vagrant VM and this works fine. I cannot find why this does not work in Docker...
You must be sure the glib version is recent enough, i.e. `pkg-config --modversion glib-2.0` must return 2.53.2. Apart from that, if you are building the toolchains following the documented snippet it should work:
```bash
cd /home/nicola/workdir/aur-fedora-mingw/aur
rm */*.pkg.tar.xz # Just to be sure to rebuild everything
env - TERM=$TERM PATH=/usr/bin ./build-all i686
env - TERM=$TERM PATH=/usr/bin ./build-all x86_64
```
In any other case you must show me exactly how you start the build process.
Thanks. I just relaunched a build with a check on the glib version. I will let you know.
I use the same commands except I just build for x86_64 not for i686. Do you think it may be an issue ?
> I got GLIB_VERSION=2.52.3. Do you really have a different version (2.53.2) or is it a typo ?
It's a typo :)
Also, be sure to uninstall all the old packages between your tests. With the new build system is enough to do a `pacman -Rscu afm-i686 && pacman -Rscu afm-x86_64`.
I rebuilt everything and did check the host glib version but I still got the same issue:
Invalid GType function: 'g_date_get_type'
Failed to find symbol 'g_date_get_type'
Command '['env', 'WINEARCH=win64', 'WINEPREFIX=/home/nicola/workdir/aur-fedora-mingw/aur/afm-mingw-w64-gobject-introspection/src/win64', 'DISPLAY=', '/usr/bin/wine', u'/home/nicola/workdir/aur-fedora-mingw/aur/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.52.1-build/tmp-introspectFBfRh7/GLib-2.0.exe', u'--introspect-dump=/home/nicola/workdir/aur-fedora-mingw/aur/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.52.1-build/tmp-introspectFBfRh7/functions.txt,/home/nicola/workdir/aur-fedora-mingw/aur/afm-mingw-w64-gobject-introspection/src/gobject-introspection-1.52.1-build/tmp-introspectFBfRh7/dump.xml']' returned non-zero exit status 1
make[2]: *** [Makefile:3533: GLib-2.0.gir] Error 1
I only built the 64b version. Do you think not building the 32b version may cause this ?
> Do you think not building the 32b version may cause this ?
No, I just built it without issues. My guess is there is a missing dependency.
> RUN git clone 'https://github.com/ntd/aur-fedora-mingw.git' aur && echo 1907
Is then `aur` owned by user:users? What does `echo 1907` mean?
Apart from that everything seems fine. Could you please upload somewhere the full log? I'm pretty sure the `Invalid GType function` is not the real problem here.
I will check but "aur" should be owned by user since the commands run as user (USER "$USERNAME")
"1907" does not mean anything. It was just a trick to force docker to rebuild the step.
I do not have the log anymore. I will rebuild and send it to you. Thanks for your help !
I just refactored everything to provide docker support, so I can replicate your issue.
The problem is still there: there is something in docker preventing the introspection of the cross-compiled libraries. `g_date_get_type` just happens to be the first symbol of the first library [to be analyzed](https://git.gnome.org/browse/gobject-introspection/tree/girepository/gdump.c?h=1.53.4#n110).
I spent an insane amount of time trying without success different environment variables combinations, to the point I believe this is not environment related. I also checked the DLL info spit out by wine from the faulty command: the working and non-working logs look pretty similar (apart the different loading order).
It seems to be something related to the way gobject-introspection works... such as a missing file or similar. Maybe I strip out from the packages something vital for gobject-introspection that a desktop system has normally installed, so it can be seen only in docker.
Anyway many thanks for the report. I will try to contact the gobject-introspection developers when I have more time to dedicate (not in the near future though) because the issue looks quite troublesome.
> It seems to be something related to the way gobject-introspection works... such as a missing file or similar.
This is suggested also by the fact that if I move `GLib-2.0.exe` from docker to the host I can execute it successfully with wine!
Thank you very much for your time and analysis.
What is killing me is that we already had this issue one year ago and we managed to make it work in docker (without any big change, just a whole rebuild and some cleaning in the docker images).
No luck this time we gave up and used a virtual machine with vagrant to build our project.