-
Notifications
You must be signed in to change notification settings - Fork 3
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
Comments
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.
|
Thanks for your answer. Good news you're working on an update ! |
I'd say this is the result of a previous linking error or missconfiguration. |
Maybe related: I had similar problems while building pango (same error with different symbol). I had to apply |
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). Tough job ... Thank you again for your work and for the help ! |
You are welcome. I learnt by myself that |
Is it OK to use now the version you just pushed ? Or is it still a work in progress ? |
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. |
Based on your work I manage to get it work with python 3. |
If you manage to make a pull-request I will be happy to try to merge it. |
I will try to make a clean pull request. |
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 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:
This usually unsets Anyway I left a way to pass custom flags if you really want to, e.g.:
It is worth noting that maybe those flags are completely useless and
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 I compiled both toolchains from ground without issues. Please refer to the updated documentation 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 still get the same error... |
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. |
You must be sure the glib version is recent enough, i.e. 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 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 |
OK. For now in docker I always start from scratch. |
I rebuilt everything and did check the host glib version but I still got the same issue: Invalid GType function: 'g_date_get_type' I only built the 64b version. Do you think not building the 32b version may cause this ? |
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
|
No, I just built it without issues. My guess is there is a missing dependency.
Is then Apart from that everything seems fine. Could you please upload somewhere the full log? I'm pretty sure the |
I will check but "aur" should be owned by user since the commands run as user (USER "$USERNAME") |
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. 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. |
This is suggested also by the fact that if I move |
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. |
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 :
fedora-mingw-w64-glib2 has been successfully installed before.
Do you have any clue how to fix this issue ?
Thank you very much !
The text was updated successfully, but these errors were encountered: