Package Details: mingw-w64-gtk3 3.24.41-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-gtk3.git (read-only, click to copy)
Package Base: mingw-w64-gtk3
Description: GObject-based multi-platform GUI toolkit (mingw-w64)
Upstream URL: https://www.gtk.org
Keywords: gnome
Licenses: LGPL
Submitter: lantw44
Maintainer: lantw44
Last Packager: lantw44
Votes: 10
Popularity: 0.000000
First Submitted: 2013-04-25 13:26 (UTC)
Last Updated: 2024-04-03 15:25 (UTC)

Latest Comments

1 2 3 4 Next › Last »

lantw44 commented on 2021-09-26 13:25 (UTC)

＠Martchus I have added gtk-doc to makedepends. gtk-doc is disabled in the build, but autogen.sh needs it to run.

Martchus commented on 2021-09-25 21:46 (UTC)

It looks like a dependency for making the documentation is missing (or building the documentation should be disabled):

==> Starting build()...
which: no gtkdocize in (/usr/lib/ccache/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
*** No GTK-Doc found, please install it ***

lantw44 commented on 2016-11-25 10:13 (UTC)

I saw the undefined reference problem on another machine today. I resolved it by rebuilding mingw-w64-gettext.

lantw44 commented on 2016-11-03 15:03 (UTC)

I know that some GTK apps can have data files, such as icons, style sheets, GtkBuilder xml builtin into binaries, but translation is provided by gettext and requires a lot of other files. I remember that GTK itself has a lot of data files builtin, including GtkBuilder UI definitions and Adwaita theme.

Martchus commented on 2016-11-01 15:41 (UTC) (edited on 2016-11-01 15:42 (UTC) by Martchus)

> No, it links against msvcrt.dll So I conclude HAVE__LOCK_FILE is not defined when you build it but it was when I encountered the linker error. I will further investigate this when rebuilding anyways. > The patch you provided could not be cleanly applied and built on my machine, and I don't think simply renaming DllMain is going to work. I did not provide the patch - it is from MXE. Since they still provide the old version 3.14.4 it is no surprise that the patch needs rebasing. But considering the discussion we can forget the patch anyways. > I don't know why we still need static linking if the some features of the library itself already need multiple files (translation files, gdk-pixbuf loaders, possibly gsettings schemas) to work properly ... That is unfortunately true and the reason I designed my own Qt-based applications in a way that you can specify translations and icon themes to be built-in at compile time. Of course that made only sense for me because Qt supports static libs. But I doubt any GTK applications will offer such build options. So the point remains and I also think static GTK is currently not worth the effort.

lantw44 commented on 2016-10-31 16:48 (UTC)

No, it links against msvcrt.dll. The patch you provided could not be cleanly applied and built on my machine, and I don't think simply renaming DllMain is going to work. There are some discussion on GNOME Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=698118. I don't know why we still need static linking if the some features of the library itself already need multiple files (translation files, gdk-pixbuf loaders, possibly gsettings schemas) to work properly ...

Martchus commented on 2016-10-30 16:28 (UTC)

Thanks for the answer. I always build in a clean chroot, too. Maybe it is a sporadic bug. (I just tried my fixed version after it failed once.) Does your libgtk-3-0.dll link against MSVCR90.DLL? About building static libs: All dependencies already provide static libraries so I guess there would be no need modifying them. A patch would be provided by MXE: https://github.com/mxe/mxe/blob/master/src/gtk3-1-fixes.patch But not sure whether this actually works.

lantw44 commented on 2016-10-30 14:18 (UTC)

No, I cannot reproduce it. I ran the build on a clean installation of Arch Linux today, but I saw no build failure in mingw-w64-gtk3. It also built without problems in the clean chroot created by multilib-build script available in devtools package. GTK+ upstream doesn't support building static libraries on Windows. I never try to do it, and I don't know how other dependent packages like mingw-w64-adwaita-icon-theme will need to be modified to support it. Unless someone provides a clean and working patch to enable static builds, I am not going to support it.

Martchus commented on 2016-10-28 22:36 (UTC)

This builds for me: https://github.com/Martchus/PKGBUILDs/tree/master/gtk3/mingw-w64 I've chose to add the linker flag. Not sure how it affects support for older Windows versions. The updated version still doesn't include static libs and the warning is still there.

Martchus commented on 2016-10-28 19:29 (UTC)

I'm getting the following errors when trying to build shared libgtk-3-0.dll: .libs/libgtk_3_la-gtkutils.o: In function `gtk_read_line': /build/mingw-w64-gtk3/src/gtk+-3.22.2/build-i686-w64-mingw32/gtk/../../gtk/gtkutils.c:112: undefined reference to `_imp___lock_file' /build/mingw-w64-gtk3/src/gtk+-3.22.2/build-i686-w64-mingw32/gtk/../../gtk/gtkutils.c:190: undefined reference to `_imp___unlock_file' /build/mingw-w64-gtk3/src/gtk+-3.22.2/build-i686-w64-mingw32/gtk/../../gtk/gtkutils.c:190: undefined reference to `_imp___unlock_file' Can you reproduce the issue? The concerning symbols would be exported by libmsvcrt.a (libmsvcrt90.a or higher) so adding -lmsvcr90 to linker flags will fix this issue. Another fix would be removing definition of HAVE__LOCK_FILE in config.h.win32 so the functions aren't used anymore. Additionally I'm getting the following warning: *** Warning: Trying to link with static lib archive /usr/i686-w64-mingw32/lib/libintl.dll.a. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because the file extensions .a of this argument makes me believe *** that it is just a static archive that I should not use here. Not sure how to disable it. It seems that the build system thinks the importlib is a static library. To your comments from 2014: Having static libs also would be nice, indeed. Not sure how to enable it, though. In other autotools-based project this usually works out of the box by just passing the right configure options (including pango as far as I see). GTK+ seems to be a bit odd in this regard.

1 2 3 4 Next › Last »