Package Details: mingw-w64-gtk3 3.24.34-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.000595
First Submitted: 2013-04-25 13:26 (UTC)
Last Updated: 2022-05-30 15:43 (UTC)

Latest Comments

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.

lantw44 commented on 2014-10-11 16:35 (UTC)

Can you provide the patch you used to build static gtk? There is no patch in mingw-w64-pango.

lxndr commented on 2014-10-10 13:41 (UTC)

It is simply that a single .exe looks nicer than the .exe and lots of .dlls. Anyway, I tried forcing the configure script to ignore platform check - and it can actually build static libraries. My application even worked with gtk.a linked statically and all the rest of libraries (like gdk, pango) as DLLs. One big problem is that both GTK and GDK has DllMain which causes linking errors. The devs use DLLs entry point for something, this is why they don't allow building statics for Windows. PS: I'm not asking for anything, just sharing my thoughts. :)

lantw44 commented on 2014-10-10 08:07 (UTC)

Do we really need static libraries? The staticlibs does not mean it contains static libraries. It is used to keep .dll.a files.

lxndr commented on 2014-10-09 00:20 (UTC)

That is to link DLLs. configure says "WARNING: Disabling static library build, must build as DLL on Windows." Either static build is not supported or there's a patch to force it as it was for pango library.

lantw44 commented on 2014-10-07 16:00 (UTC)

This package has .dll.a installed in /usr/i686-w64-mingw32/lib.

lxndr commented on 2014-10-07 15:54 (UTC)

The package doesn't have static librarbies.

xantares commented on 2014-10-01 06:38 (UTC)

this line is useless (comes with base-devel): makedepends+=(autoconf automake libtool)

Schala commented on 2013-10-31 22:32 (UTC)

Flagging this since glib2 got updated

lantw44 commented on 2013-10-10 05:26 (UTC)

mingw-w64-glib2 is out-of-date, so I cannot update mingw-w64-gtk3 on AUR now. I have a PKGBUILD for mingw-w64-gtk3 3.10.0, which can be downloaded from the following sites: http://www.tfcis.org/~lantw44/cgit/cgit.cgi/AUR-PKGBUILD/tree/mingw-w64-gtk3 https://github.com/lantw44/AUR-PKGBUILD/tree/master/mingw-w64-gtk3

Schala commented on 2013-09-28 03:34 (UTC)

Thank you

Schala commented on 2013-09-28 01:29 (UTC)

Can you please stick with the version in the official repos? I can no longer build this without having to manually tinker and rebuild deps

lantw44 commented on 2013-08-22 12:58 (UTC)

I found python2 is an optional deps of glib2. I uploaded new PKGBUILD. Thank you.

ant32 commented on 2013-08-22 00:34 (UTC)

Could you please add python2 to makedepends? I'm getting the following without it installed. /bin/sh: /usr/bin/gdbus-codegen: /usr/bin/python2: bad interpreter: No such file or directory make[2]: *** [gtkdbusgenerated.h] Error 126 make[2]: Leaving directory `/build/mingw-w64-gtk3/src/mingw-w64-gtk3-3.8.2-build-i686-w64-mingw32/gtk' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/mingw-w64-gtk3/src/mingw-w64-gtk3-3.8.2-build-i686-w64-mingw32' make: *** [all] Error 2 ==> ERROR: A failure occurred in build().

ant32 commented on 2013-06-25 16:33 (UTC)

It works now. thank you.

lantw44 commented on 2013-06-25 11:54 (UTC)

Native gtk-update-icon-cache is required to build GTK+ 3. I uploaded new PKGBUILD with correct makedepends.

ant32 commented on 2013-06-24 02:58 (UTC)

I've been trying to build this package but it fails with /bin/sh: no: command not found

Schala commented on 2013-05-17 23:47 (UTC)

I am thrilled by this! However, you may want to consider putting the patch files into the package instead of linking them. I made that mistake regarding patch files for various packages in the official repos here for their mingw-w64 counterparts. Then the versions got bumped and the patches were upstreamed. It's better to have a flagged package that still works/builds than to have one that errors out whenever a new version comes along.

lantw44 commented on 2013-05-17 08:27 (UTC)

It seems that GTK+ 3 for Windows is not officially supported, but some people have worked on it. I found GTK+ 3 binary for Windows in Fedora build system: http://koji.fedoraproject.org/koji/packageinfo?packageID=12028 Someone built an installer for GTK+ 3 on Windows. http://www.tarnyko.net/en/?q=node/20 Recently, a new git repository was opened on GNOME to build GTK+ 3 for Windows. https://git.gnome.org/browse/gtk3-build-system/

Schala commented on 2013-05-17 02:31 (UTC)

When did GTK+ 3 start supporting Windows? I was surprised to see this pop up.