Package Details: mingw-w64-glib2 2.52.3-1

Git Clone URL: (read-only)
Package Base: mingw-w64-glib2
Description: Low level core library (mingw-w64)
Upstream URL:
Keywords: glib2 gnome gtk gtk2 gtk3 mingw mingw-w64
Licenses: LGPL
Submitter: brcha
Maintainer: Schala
Last Packager: Schala
Votes: 17
Popularity: 0.660113
First Submitted: 2012-06-13 19:15
Last Updated: 2017-07-29 01:18

Latest Comments

Martchus commented on 2018-01-31 20:22

@xantares You mean the native/Linux executables are under /usr/{i686,x86_64}-w64-mingw32/bin? Those are not so nice, indeed.

However, I'm not sure that removing them is a good idea, too. Maybe some of the packages requiring glib2 need those exe files at build time? If that is true, we could use the same approach as in the Qt packages (put stuff under /usr/x86_64-w64-mingw32/lib/qt/bin and have prefixed symlinks under /usr/bin) or just use the executables from the regular glib2 package. Not sure whether the 2nd option is possible (eg. it would not work for Qt).

xantares commented on 2018-01-31 11:04

Could you cleanup the exe files? xan.

lantw44 commented on 2017-02-26 06:24

Can we add mingw-w64-gettext to depends? libglib-2.0-0.dll needs libintl-8.dll.

drakkan commented on 2017-02-01 23:30

dll.a are ok if you compile with mingw-w64 but if you want to link in visual studio you need a .lib,

gstreamer official windows binaries are builded with mingw

and they work with msvc

.lib are generated this way:

I need .lib for glib to be able to link my gstreamer packages in visual studio,

I know about c++ but glib is a c library.

Actually the only problem is that .lib generated with dlltool in arch don't work with all msvc versions but this could be fixed in future updates, anyway packaging .def files make easier to regenerate the .lib directly on windows using lib.exe

Martchus commented on 2017-02-01 21:57

Why are the contained import libraries not sufficient? Note that import libraries have the extension `dll.a` in mingw-w64 packages (and not `lib`).

I would also say that it is not recommend to mix mingw-w64 with msvc. It might work with pure C libs but will fail when using C++.

drakkan commented on 2017-02-01 21:08

please add import library for linking in Visual Studio, patch here:

the generated .lib does not work with all msvc compiler versions anyway having the .def files make easier regenerate the .lib directly on windows using lib.exe instead of dlltool

drakkan commented on 2017-01-11 16:48

Can you please apply the following patch?

Martchus commented on 2016-08-17 22:15

You've just reminded me to push the commit to mingw-w64-gettext.

Schala commented on 2016-08-17 22:07

ack, forgot the last part -_-

Martchus commented on 2016-08-13 14:15

pnyetmja: I will fix this problem with the static Qt package in the next update. To avoid hard coding I will use pkgconfig.

However, this package would need a slight fix to make it work:
This is because the bug pnyetmja already mentioned:
But please do not include this fix until the pkgconfig file for intl is included in mingw-w64-gettext.

pnyetmja commented on 2015-09-26 13:33

Adding -liconv after -lintl in qmake.conf solves problem
Thank you

pnyetmja commented on 2015-09-26 13:25

Adding -liconv after -lintl to qmake.conf solves problem.

ant32 commented on 2015-09-25 03:12

Manually adding libraries in the .pro file will probably add it in the wrong place in your case. Linking needs to be done in the right order. You can sometimes further debug the issue by modifying the last command executed.I'm guessing it needs to go after -lglib-2.0 or -lintl.

To make this permanent you'll need to add it in
just search for 'glib' in the file.
If you get it working please let us know how you did it.

pnyetmja commented on 2015-09-24 21:39

I've installed packages from this repo$arch

And tried to compile statically simple qt gui project but I got that error

Build with shared libs succeeds

Also I manually added LIBS += -L/usr/x86_64-w64-mingw32/lib -liconv to Qt .pro file but static build failed.
That dir contains libs for windows, I suppose?

pnyetmja commented on 2015-09-24 21:38

I've installed packages from this repo$arch

And tried to compile statically simple qt gui project then I got that error

Build with shared libs succeeds

Also I manually added LIBS += -L/usr/x86_64-w64-mingw32/lib -liconv to Qt .pro file but static build failed.
That dir contains libs for windows, I suppose?

Schala commented on 2015-09-24 17:55

Also, I'd rather wait to update glib2 until official repo updates. I've gotten complaints before for not following official repo version. It's in testing at the moment though.

Schala commented on 2015-09-24 17:53

Weird. libiconv should be installed with gettext. Which libiconv are you using? libiconv or win-iconv?

pnyetmja commented on 2015-09-24 08:46

Undefined reference error when statically linking with mingw-w64-qt5-base-static libs

x86_64-w64-mingw32-g++ -g -static -Wl,-subsystem,windows -mthreads -o release/GUI.exe release/main.o release/gui.o release/moc_gui.o -lmingw32 -lqt5main -L/usr/x86_64-w64-mingw32/lib -liconv -lQt5Widgets -lQt5Gui -lcomdlg32 -loleaut32 -limm32 -ljpeg -lpng -lharfbuzz -lglib-2.0 -lintl -lwinmm -lQt5Core -lole32 -luuid -lws2_32 -ladvapi32 -lshell32 -lkernel32 -lz -lpcre16 -lEGL -lGLESv2 -ld3d9 -ldxguid -lgdi32 -luser32
/usr/x86_64-w64-mingw32/lib/libintl.a(dcigettext.o):(.text+0x55d): undefined reference to `libiconv'
/usr/x86_64-w64-mingw32/lib/libintl.a(dcigettext.o):(.text+0x8df): undefined reference to `libiconv_open'
/usr/x86_64-w64-mingw32/lib/libintl.a(dcigettext.o):(.text+0xa69): undefined reference to `libiconv_open'
/usr/x86_64-w64-mingw32/lib/libintl.a(relocatable.o):(.text+0x46): undefined reference to `libiconv_set_relocation_prefix'
collect2: error: ld returned 1 exit status

ant32 commented on 2015-03-04 18:08

@Infinity Schala is probably trying to build 2.42.2
According to
Always try to match the pkgver in your mingw-w64 packages to the pkgver of the corresponding regular packages in the official Arch Linux repos (not the testing repos).

Building 2.42.2 also works with that flag. Probably a better solution is to add this and you don't need that flag

Martchus commented on 2015-03-04 17:20

You don't have to use sed to get rid of the -Werror=implicit-function-declaration flags. Adding GLIB_WARN_CFLAGS= in the configure line worked for me.

I did not get any reference errors (compiling the current version 2.43.91).
Are you sure that you cleaned everything after the failure of the first try without the flags omitted?
I'm also wondering why static and shared can not be build at the same time.

Schala commented on 2015-03-03 23:18

Yeah I tried sed'ing out the -Werror=implicit-function-declaration but got undefined references when linking. Fedora has MinGW's glib at 2.43, which I'm guessing would work, but I'd rather stick with the version of Arch's glib. Hopefully ant32 will come out with a patch or PKGBUILD fix, but if not, the worst that'll happen is waiting til Arch updates the native glib to 2.43 or 2.44.

Martchus commented on 2015-03-03 20:07

I can only build this package when clearing GLIB_WARN_CFLAGS because otherwise occurring warnings are treat as erros preventing the build process to complete.

The problem remains when building the current version 2.43.91.

hanckmann commented on 2015-02-15 18:29

I have installed mingw-w64-gettext.

but I still get this error:
*** You must have either have gettext support in your C library, or use the
*** GNU gettext library. (

==> ERROR: A failure occurred in build().
==> ERROR: Makepkg was unable to build mingw-w64-glib2.

xantares commented on 2014-12-14 18:25

should makedepend on mingw-w64-configure instead of mingw-w64-gcc

ant32 commented on 2014-12-14 16:49

/startdir/PKGBUILD: line 42: i686-w64-mingw32-configure: command not found

xantares commented on 2014-11-19 16:57

I did not get this error the last I built it as I just
took this PKGBUILD in this current state and added my sed line for nametoindex.
it looks like you added several patches (where do they come from btw ?), maybe they are the source of this trouble.
I filled an orphan request so as to update it the best I can, hope it will be accepted soon.

riguk commented on 2014-11-19 15:03

hello again,

i made some progress but now i am stuck when compiling gio:

CCLD glib-compile-schemas.exe
glib-compile-schemas.o:glib-compile-schemas.c:(.text+0xdc): undefined reference to `__imp_g_ascii_table'
glib-compile-schemas.o:glib-compile-schemas.c:(.text+0x82c): undefined reference to `__imp_g_ascii_table'
glib-compile-schemas.o:glib-compile-schemas.c:(.text+0x2723): undefined reference to `__imp_g_ascii_table'
C:/msys64/mingw64/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/bin/ld.exe: glib-compile-schemas.o: bad reloc address 0x8 in section `.data'
collect2.exe: error: ld returned 1 exit status
Makefile:2029: recipe for target 'glib-compile-schemas.exe' failed

does somebody has the same behavior ?

note: my corporate proxy is blocking pastebin like site.

riguk commented on 2014-11-18 15:52

by the way should G_OS_WIN32 be set when using mingw-64 ?


case $host in
glib_os="#define G_OS_UNIX
#define G_PLATFORM_WIN32
#define G_WITH_CYGWIN"
*-*-mingw*) --> catches also MINGW64_XXXX
glib_os="#define G_OS_WIN32
#define G_PLATFORM_WIN32"
glib_os="#define G_OS_UNIX"

it seems there is more than one way to solve this.

riguk commented on 2014-11-18 15:36

real error is at g_socket.c line 1934:

#if !defined(HAVE_IF_NAMETOINDEX) && defined(G_OS_WIN32)
static guint
if_nametoindex (const gchar *iface)


so yes, if HAVE_IF_NAMETOINDEX is set it will not define if_nametoindex a second time and thus there this error won't appear.

xan, how do you manage to get compilation working ? by patching directly gsocket.c ? -this works for me -

riguk commented on 2014-11-18 15:10

i added the sed line plus my patch in prepare func:

prepare() {
cd "$srcdir/glib-$pkgver"

patch -Np1 -i "$srcdir/0001-Use-CreateFile-on-Win32-to-make-sure-g_unlink-always.patch"
patch -Np1 -i "$srcdir/0003-g_abort.all.patch"
patch -Np1 -i "$srcdir/0004-glib-prefer-constructors-over-DllMain.patch"
patch -Np0 -i "$srcdir/0005-glib-send-log-messages-to-correct-stdout-and-stderr.patch"
patch -Np1 -i "$srcdir/0015-fix-stat.all.patch"
patch -Np1 -i "$srcdir/0017-glib-use-gnu-print-scanf.patch"
patch -Np1 -i "$srcdir/0021-use-64bit-stat-for-localfile-size-calc.all.patch"
patch -Np1 -i "$srcdir/0023-print-in-binary-more-for-testing.all.patch"
patch -Np1 -i "$srcdir/0024-return-actually-written-data-in-printf.all.patch"
patch -Np1 -i "$srcdir/0025-glib-update-valgrind-h-stdint.patch"
patch -Np1 -i "$srcdir/0026-fix-if-nametoindex-detection.patch" --> my patch
sed -i "s|#undef HAVE_IF_NAMETOINDEX|#define HAVE_IF_NAMETOINDEX 1|g" --> your sed


but it still doest not work and i really think this is because create on the fly.

The C compilation error is in multiple declaration of function if_nametoindex and not lack of declaration. I wonder if having HAVE_IF_NAMETOINDEX set will really solve the conflict between iphlpapi.h and netioapi.h headers.

xantares commented on 2014-11-18 14:04

no, really just insert the sed line in the prepare section and you'll be fine

riguk commented on 2014-11-18 13:31


i managed by my own to create the patch and made it works then i discovered that was generated as stated in the first lines of the file --'

/* Generated from by autoheader. */

so that's why i couldn't managed to apply your modification.

i am currently digging in autoconf documentation to find out how autoheader works.

xantares commented on 2014-11-18 12:33

how to create a patch ? read this:

or you just use the previous sed I gave previously, read the fraking comments.


riguk commented on 2014-11-18 11:23


you are right xantares, how could we solve this ? i need glib at work and i am ready to spend some time to get it work!

./configure output says:
checking for

but that should be yes because this function is declared in system headers:

grep -r if_nametoindex /usr/include/
/usr/include/cygwin/if.h:extern unsigned if_nametoindex (const char *);
/usr/include/cygwin/version.h: 162: New struct ifreq. Export if_nametoindex, if_indextoname,
/usr/include/w32api/netioapi.h:NET_IFINDEX WINAPI if_nametoindex(

i don't known why AC_CHECK_FUNCS( if_nametoindex if_indextoname) in does not work.

best correction would be to make it work. but that's beyond my abilities.
a work around is to create add a patch like this:

cat 0026-fix-if-nametoindex-detection.patch
--- glib-2.42.0/ 2014-11-18 11:37:41.519237600 +0100
+++ glib-2.42.0/ 2014-11-18 11:38:01.253364100 +0100
@@ -193,7 +193,7 @@

/* Define to 1 if you have the `if_nametoindex' function. */

/* Define to 1 if you have the `inotify_init1' function. */

but i can't manage to get it work! does somebody can explain to me how to create a patch for makepkg-minggw ?

xantares commented on 2014-11-01 20:10

If I force the detection build is ok, but that's not clean:
sed -i "s|#undef HAVE_IF_NAMETOINDEX|#define HAVE_IF_NAMETOINDEX 1|g"

xantares commented on 2014-11-01 17:24

the builds fails, I suspect the new mingw-crt 3.3.0 provides if_nametoindex (netioapi.h) and it's not properly detected:

xantares commented on 2014-10-31 09:56


i've got an error:

CC libgio_2_0_la-gsocketaddressenumerator.lo
CC libgio_2_0_la-gsocketclient.lo
CC libgio_2_0_la-gsocketconnectable.lo
CC libgio_2_0_la-gsocketconnection.lo
CC libgio_2_0_la-gsocketcontrolmessage.lo
CC libgio_2_0_la-gsocketinputstream.lo
CC libgio_2_0_la-gsocketlistener.lo
CC libgio_2_0_la-gsocketoutputstream.lo
CC libgio_2_0_la-gsubprocesslauncher.lo
../../gio/gsocket.c:1934:1: error: conflicting types for 'if_nametoindex'
if_nametoindex (const gchar *iface)
In file included from /usr/i686-w64-mingw32/include/iphlpapi.h:16:0,
from ./gnetworking.h:35,
from ../../gio/gnetworkingprivate.h:22,
from ../../gio/gsocket.c:60:
/usr/i686-w64-mingw32/include/netioapi.h:319:20: note: previous declaration of 'if_nametoindex' was here
NET_IFINDEX WINAPI if_nametoindex(
CC libgio_2_0_la-gsubprocess.lo
Makefile:2804: recipe for target 'libgio_2_0_la-gsocket.lo' failed
make[4]: *** [libgio_2_0_la-gsocket.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory '/tmp/yaourt-tmp-root/aur-mingw-w64-glib2/src/glib-2.42.0/build-i686-w64-mingw32-static/gio'
Makefile:3932: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/tmp/yaourt-tmp-root/aur-mingw-w64-glib2/src/glib-2.42.0/build-i686-w64-mingw32-static/gio'
Makefile:1762: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/tmp/yaourt-tmp-root/aur-mingw-w64-glib2/src/glib-2.42.0/build-i686-w64-mingw32-static/gio'
Makefile:1206: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/tmp/yaourt-tmp-root/aur-mingw-w64-glib2/src/glib-2.42.0/build-i686-w64-mingw32-static'
Makefile:847: recipe for target 'all' failed
make: *** [all] Error 2
==> ERROR: A failure occurred in build().

Schala commented on 2013-10-31 21:01

Thank you Thank you!!!

ant32 commented on 2013-10-28 17:03

ant32 commented on 2013-10-28 17:03

Fixed src tarball and updated to 2.38.1 and PKGBUILD
View Changes
This will be used in the mingw-w64 repo

ant32 commented on 2013-10-14 23:39

Updated src tarball to 2.38.0 and PKGBUILD & patches
View Changes

xantares commented on 2013-10-07 17:41

There are useless libtool (.la) files in arch/lib, please add !libtool option

xantares commented on 2013-10-07 12:36

There are useless libtool (.la) files in arch/lib

ekpyron commented on 2013-09-06 00:07

This tarball at least works for me.

ant32 commented on 2013-09-05 23:52

@ekpyron could you post a src tarball for others. Brcha won't be doing much for a week or two.

ekpyron commented on 2013-09-05 23:42

Please update to 2.37.7 and remove the no longer necessary glib-formatstring.patch. The current PKGBUILD doesn't work for me, but with these little changes everything works fine.

Schala commented on 2013-04-17 22:51

Sounds reasonable I guess

brcha commented on 2013-03-15 21:46

Can I add a negative dependency somehow? Perhaps put plibc into conflicts array?

Schala commented on 2013-03-15 21:44

Yep, plibc was the culprit. It builds fine now.

brcha commented on 2013-03-15 11:22

local/mingw-w64-plibc 0.1.7-1
A POSIX compliant libc for Windows

I don't have that and nl_langinfo should be from libc. Could you try removing mingw-w64-plibc and trying to recompile glib2?

Schala commented on 2013-03-15 05:40

pacman -Qs mingw-w64:
build log:

brcha commented on 2013-01-22 18:25

@Schala, I have no idea what is the problem. It compiles prefectly on my system. Could you provide some more info, like output of "pacman -Qs mingw-w64" and a complete build log?

Schala commented on 2013-01-21 16:10

CCLD dir.exe
CC pattern.o
CCLD pattern.exe
CC logging.o
CCLD logging.exe
CC error.o
CCLD error.exe
CC bookmarkfile.o
CCLD bookmarkfile.exe
CC gdatetime.o
../../../glib/tests/gdatetime.c: In function 'test_GDateTime_get_utc_offset':
../../../glib/tests/gdatetime.c:682:13: warning: variable 'ts' set but not used [-Wunused-but-set-variable]
../../../glib/tests/gdatetime.c: In function 'test_strftime':
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'C' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'e' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'F' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'g' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'G' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'h' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'n' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'r' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'R' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 't' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'T' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'u' in format [-Wformat]
../../../glib/tests/gdatetime.c:1235:7: warning: unknown conversion type character 'V' in format [-Wformat]
CCLD gdatetime.exe
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x2237): undefined reference to `nl_langinfo'
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x2310): undefined reference to `nl_langinfo'
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x241d): undefined reference to `nl_langinfo'
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x26ca): undefined reference to `nl_langinfo'
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x27ad): undefined reference to `nl_langinfo'
../../glib/.libs/libglib-2.0.a(gdatetime.o):gdatetime.c:(.text+0x29ce): more undefined references to `nl_langinfo' follow
/usr/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: ../../glib/.libs/libglib-2.0.a(gdatetime.o): bad reloc address 0x124 in section `.rdata'
/usr/lib/gcc/i686-w64-mingw32/4.7.2/../../../../i686-w64-mingw32/bin/ld: final link failed: Invalid operation
collect2: error: ld returned 1 exit status
make[4]: *** [gdatetime.exe] Error 1

entidi commented on 2012-10-11 17:06

0001-win32-fix-build-after-bug-674452.patch is no more needed (commit af3b167). A couple of additional patches should be applied (

svanheulen commented on 2012-08-10 20:48

This needs to makedepend on mingw-w64-gcc instead of mingw32-gcc