Package Details: mingw-w64-gtk3 3.24.52-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: neoapps-dev
Last Packager: neoapps-dev
Votes: 11
Popularity: 0.022675
First Submitted: 2013-04-25 13:26 (UTC)
Last Updated: 2026-07-14 09:53 (UTC)

Latest Comments

1 2 3 4 Next › Last »

neoapps-dev commented on 2026-07-14 09:54 (UTC)

Patch applied, thanks @Denzy7

Denzy7 commented on 2026-05-29 09:25 (UTC)

please update to 3.24.52 to fix gdk compile error. Also the extracted tar path has changed. Here is a quick patch 

diff --git a/PKGBUILD b/PKGBUILD
index 66fbe07..0516d07 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,6 +1,6 @@
 # Maintainer: NEOAPPS <neo@obsidianos.xyz> <asd22.info@gmail.com>
 pkgname=mingw-w64-gtk3
-pkgver=3.24.51
+pkgver=3.24.52
 pkgrel=1
 pkgdesc='GObject-based multi-platform GUI toolkit (mingw-w64)'
 arch=('any')
@@ -27,13 +27,12 @@ depends=(
 options=('!strip' '!buildflags' 'staticlibs')
 source=(
   "https://gitlab.gnome.org/GNOME/gtk/-/archive/${pkgver}/gtk-${pkgver}.tar.gz")
-sha256sums=(
-  'f3c87a20b3380b69efa720f412a0fea6ab6edce021f8ffaf5c4531fe1321b24f')
+sha256sums=('e62514019679f831fcb37f3d294a761c3a6c14f1d346745ad11d70c2be17146e')

 _architectures=('i686-w64-mingw32' 'x86_64-w64-mingw32')

 prepare() {
-  cd "${srcdir}/gtk+-${pkgver}"
+  cd "${srcdir}/gtk-${pkgver}"
   local source_file
   for source_file in "${source[@]}"; do
     case "${source_file}" in
@@ -45,7 +44,7 @@ prepare() {
 }

 build() {
-  cd "${srcdir}/gtk+-${pkgver}"
+  cd "${srcdir}/gtk-${pkgver}"
   for _arch in "${_architectures[@]}"; do
     mkdir -p "build-${_arch}"
     cd "build-${_arch}"
@@ -63,7 +62,7 @@ build() {
 }

 package() {
-  cd "${srcdir}/gtk+-${pkgver}"
+  cd "${srcdir}/gtk-${pkgver}"
   for _arch in "${_architectures[@]}"; do
     cd "build-${_arch}"
     DESTDIR="${pkgdir}" ninja install

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.

1 2 3 4 Next › Last »