search

ntd / aur-fedora-mingw

ArchLinux PKGBUILDs based on Fedora for cross-buildinging GTK+2 and GTK+3 applications (win32 and win64)
MIT License
6 stars 3 forks source link

Cannot build afm-mingw-w64-gobject-introspection : Failed to find symbol 'g_date_get_type' #2

Open jcnoir opened 8 years ago

jcnoir commented 8 years ago

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 !

ntd commented 8 years ago

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).

jcnoir commented 8 years ago

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 ?

ntd commented 8 years ago

I'd say this is the result of a previous linking error or missconfiguration.

ntd commented 8 years ago

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.

jcnoir commented 8 years ago

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.

jcnoir commented 8 years ago

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 ?

jcnoir commented 8 years ago

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 !

ntd commented 8 years ago

You are welcome. I learnt by myself that gobject-introspection is really picky.

jcnoir commented 8 years ago

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 ?

ntd commented 8 years ago

I just compiled the whole GTK+2/3 toolchain (with gobject-introspection and 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.

jcnoir commented 8 years ago

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/

ntd commented 8 years ago

If you manage to make a pull-request I will be happy to try to merge it.

jcnoir commented 8 years ago

I will try to make a clean pull request.

jcnoir commented 7 years ago

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 ?

ntd commented 7 years ago

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.

ntd commented 6 years ago

@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 for instructions.

Let me know if you still have problems.

jcnoir commented 6 years ago

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 !

jcnoir commented 6 years ago

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.

ntd commented 6 years ago

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.

jcnoir commented 6 years ago

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...

ntd commented 6 years ago

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:

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.

jcnoir commented 6 years ago

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 ?

jcnoir commented 6 years ago

I got GLIB_VERSION=2.52.3. Do you really have a different version (2.53.2) or is it a typo ?

ntd commented 6 years ago

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.

jcnoir commented 6 years ago

OK. For now in docker I always start from scratch.

jcnoir commented 6 years ago

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 ?

jcnoir commented 6 years ago

Here is my docker file for reference:

FROM base/archlinux

ENV TERM xterm

RUN pacman -Syu --noconfirm && pacman -S --noconfirm base-devel git

ENV USERNAME user
RUN useradd -ms /bin/bash $USERNAME
RUN echo "$USERNAME ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
USER "$USERNAME"
WORKDIR "/home/$USERNAME"

# Install the yaourt package manager
ADD install-yaourt.sh install-yaourt.sh
RUN ./install-yaourt.sh
# Enable the multilib repo for cross libs
ADD pacman-multilib.conf pacman-multilib.conf
RUN sudo sh -c "cat pacman-multilib.conf >> /etc/pacman.conf"
RUN yaourt -Syua && echo 1

# Install the cross toolchain
ENV PROJECT_FOLDER "/home/nicola/workdir/aur-fedora-mingw"
WORKDIR $PROJECT_FOLDER
RUN sudo chown user:users $PROJECT_FOLDER
RUN git clone 'https://github.com/ntd/aur-fedora-mingw.git' aur && echo 1907
RUN rm -rf src pkg && mkdir src pkg
RUN sudo chown -R user:users src pkg
WORKDIR aur
RUN rm -f */*.pkg.tar.xz
RUN export LOGFILE='pkg-config-glib.log' ; pkg-config --modversion glib-2.0 > $LOGFILE ; echo "GLIB_VERSION=$(cat $LOGFILE)"
RUN env - TERM=$TERM PATH=/usr/bin ./build-all x86_64
ntd commented 6 years ago

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.

jcnoir commented 6 years ago

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 !

ntd commented 6 years ago

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.

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.

ntd commented 6 years ago

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!

jcnoir commented 6 years ago

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.