Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jcnoir opened this issue Feb 12, 2016 · 32 comments

Comments

@jcnoir
Copy link

jcnoir commented Feb 12, 2016

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
Copy link
Owner

ntd commented Feb 12, 2016

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
Copy link
Author

jcnoir commented Feb 12, 2016

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
Copy link
Owner

ntd commented Feb 12, 2016

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

@ntd
Copy link
Owner

ntd commented Feb 12, 2016

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
Copy link
Author

jcnoir commented Feb 13, 2016

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
Copy link
Author

jcnoir commented Feb 13, 2016

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
Copy link
Author

jcnoir commented Feb 13, 2016

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
Copy link
Owner

ntd commented Feb 13, 2016

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

@ntd ntd closed this as completed Feb 13, 2016
@jcnoir
Copy link
Author

jcnoir commented Feb 13, 2016

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
Copy link
Owner

ntd commented Feb 13, 2016

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
Copy link
Author

jcnoir commented Feb 13, 2016

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
Copy link
Owner

ntd commented Feb 13, 2016

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

@jcnoir
Copy link
Author

jcnoir commented Feb 14, 2016

I will try to make a clean pull request.

@jcnoir
Copy link
Author

jcnoir commented Jul 19, 2017

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
Copy link
Owner

ntd commented Jul 19, 2017

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 ntd reopened this Jul 19, 2017
@ntd ntd closed this as completed in f2b910a Jul 29, 2017
@ntd
Copy link
Owner

ntd commented Jul 29, 2017

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

@ntd ntd reopened this Jul 29, 2017
@jcnoir
Copy link
Author

jcnoir commented Jul 29, 2017

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
Copy link
Author

jcnoir commented Jul 29, 2017

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
Copy link
Owner

ntd commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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
Copy link
Owner

ntd commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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

@ntd
Copy link
Owner

ntd commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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

@jcnoir
Copy link
Author

jcnoir commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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
Copy link
Owner

ntd commented Jul 30, 2017

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
Copy link
Author

jcnoir commented Jul 30, 2017

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
Copy link
Owner

ntd commented Aug 2, 2017

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
Copy link
Owner

ntd commented Aug 2, 2017

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
Copy link
Author

jcnoir commented Aug 2, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants