Arch Linux User Repository

Differences:

• You're using mingw-w64-{gcc,binutils}-bin and I'm using mingw-w64-{gcc,binutils}.
• You're using mingw-w64-headers-bin-5.0.4-1 and I'm using mingw-w64-headers-5.0.4-2.
• The step Linking target glib/libglib-2.0-0.dll fails for me. Since it passes for you the exact compiler invocation is not printed so I can't compare it.
• My log has a lot of messages like i686-w64-mingw32-ar: glib/glib@@glib-2.0@sha/glist.c.obj: plugin needed to handle lto object.

Note that Checking for function "vasprintf" : YES and similar do not differ.

---

Since you're not able to reproduce I suppose I'll have to investigate the issue myself. But thanks for your help so far.

here is my full build output including packages installed as deps

https://pastebin.com/DTmdjkXe

can you point me to the differences on your system? thanks!

Yes, I'm always building in a clean chroot. I can investigate the issue later and also test the autotools version.

just to be sure, are you building in a clean chroot?

Here you can find a PKGBUILD that use autotools instead of meson

https://pastebin.com/PTbGzTGB

is this one working for you?

2.58.0 fails to build here:

[358/650] Linking target glib/libglib-2.0-0.dll.
FAILED: glib/libglib-2.0-0.dll
i686-w64-mingw32-gcc  -o glib/libglib-2.0-0.dll glib/glib.o 'glib/glib@@glib-2.0@sha/deprecated_gallocator.c.obj' 'glib/glib@@glib-2.0@sha/deprecated_gcache.c
.obj' 'glib/glib@@glib-2.0@sha/deprecated_gcompletion.c.obj' 'glib/glib@@glib-2.0@sha/deprecated_grel.c.obj' 'glib/glib@@glib-2.0@sha/deprecated_gthread-depre
cated.c.obj' 'glib/glib@@glib-2.0@sha/garcbox.c.obj' 'glib/glib@@glib-2.0@sha/garray.c.obj' 'glib/glib@@glib-2.0@sha/gasyncqueue.c.obj' 'glib/glib@@glib-2.0@s
ha/gatomic.c.obj' 'glib/glib@@glib-2.0@sha/gbacktrace.c.obj' 'glib/glib@@glib-2.0@sha/gbase64.c.obj' 'glib/glib@@glib-2.0@sha/gbitlock.c.obj' 'glib/glib@@glib
-2.0@sha/gbookmarkfile.c.obj' 'glib/glib@@glib-2.0@sha/gbytes.c.obj' 'glib/glib@@glib-2.0@sha/gcharset.c.obj' 'glib/glib@@glib-2.0@sha/gchecksum.c.obj' 'glib/
glib@@glib-2.0@sha/gconvert.c.obj' 'glib/glib@@glib-2.0@sha/gdataset.c.obj' 'glib/glib@@glib-2.0@sha/gdate.c.obj' 'glib/glib@@glib-2.0@sha/gdatetime.c.obj' 'g
lib/glib@@glib-2.0@sha/gdir.c.obj' 'glib/glib@@glib-2.0@sha/genviron.c.obj' 'glib/glib@@glib-2.0@sha/gerror.c.obj' 'glib/glib@@glib-2.0@sha/gfileutils.c.obj' 
'glib/glib@@glib-2.0@sha/ggettext.c.obj' 'glib/glib@@glib-2.0@sha/ghash.c.obj' 'glib/glib@@glib-2.0@sha/ghmac.c.obj' 'glib/glib@@glib-2.0@sha/ghook.c.obj' 'gl
ib/glib@@glib-2.0@sha/ghostutils.c.obj' 'glib/glib@@glib-2.0@sha/giochannel.c.obj' 'glib/glib@@glib-2.0@sha/gkeyfile.c.obj' 'glib/glib@@glib-2.0@sha/glib-init
.c.obj' 'glib/glib@@glib-2.0@sha/glib-private.c.obj' 'glib/glib@@glib-2.0@sha/glist.c.obj' 'glib/glib@@glib-2.0@sha/gmain.c.obj' 'glib/glib@@glib-2.0@sha/gmap
pedfile.c.obj' 'glib/glib@@glib-2.0@sha/gmarkup.c.obj' 'glib/glib@@glib-2.0@sha/gmem.c.obj' 'glib/glib@@glib-2.0@sha/gmessages.c.obj' 'glib/glib@@glib-2.0@sha
/gnode.c.obj' 'glib/glib@@glib-2.0@sha/goption.c.obj' 'glib/glib@@glib-2.0@sha/gpattern.c.obj' 'glib/glib@@glib-2.0@sha/gpoll.c.obj' 'glib/glib@@glib-2.0@sha/
gprimes.c.obj' 'glib/glib@@glib-2.0@sha/gqsort.c.obj' 'glib/glib@@glib-2.0@sha/gquark.c.obj' 'glib/glib@@glib-2.0@sha/gqueue.c.obj' 'glib/glib@@glib-2.0@sha/g
rand.c.obj' 'glib/glib@@glib-2.0@sha/grcbox.c.obj' 'glib/glib@@glib-2.0@sha/grefcount.c.obj' 'glib/glib@@glib-2.0@sha/grefstring.c.obj' 'glib/glib@@glib-2.0@s
ha/gregex.c.obj' 'glib/glib@@glib-2.0@sha/gscanner.c.obj' 'glib/glib@@glib-2.0@sha/gsequence.c.obj' 'glib/glib@@glib-2.0@sha/gshell.c.obj' 'glib/glib@@glib-2.
0@sha/gslice.c.obj' 'glib/glib@@glib-2.0@sha/gslist.c.obj' 'glib/glib@@glib-2.0@sha/gstdio.c.obj' 'glib/glib@@glib-2.0@sha/gstrfuncs.c.obj' 'glib/glib@@glib-2
.0@sha/gstring.c.obj' 'glib/glib@@glib-2.0@sha/gstringchunk.c.obj' 'glib/glib@@glib-2.0@sha/gtestutils.c.obj' 'glib/glib@@glib-2.0@sha/gthread.c.obj' 'glib/gl
ib@@glib-2.0@sha/gthreadpool.c.obj' 'glib/glib@@glib-2.0@sha/gtimer.c.obj' 'glib/glib@@glib-2.0@sha/gtimezone.c.obj' 'glib/glib@@glib-2.0@sha/gtranslit.c.obj'
 'glib/glib@@glib-2.0@sha/gtrashstack.c.obj' 'glib/glib@@glib-2.0@sha/gtree.c.obj' 'glib/glib@@glib-2.0@sha/guniprop.c.obj' 'glib/glib@@glib-2.0@sha/gutf8.c.o
bj' 'glib/glib@@glib-2.0@sha/gunibreak.c.obj' 'glib/glib@@glib-2.0@sha/gunicollate.c.obj' 'glib/glib@@glib-2.0@sha/gunidecomp.c.obj' 'glib/glib@@glib-2.0@sha/
gurifuncs.c.obj' 'glib/glib@@glib-2.0@sha/gutils.c.obj' 'glib/glib@@glib-2.0@sha/guuid.c.obj' 'glib/glib@@glib-2.0@sha/gvariant.c.obj' 'glib/glib@@glib-2.0@sh
a/gvariant-core.c.obj' 'glib/glib@@glib-2.0@sha/gvariant-parser.c.obj' 'glib/glib@@glib-2.0@sha/gvariant-serialiser.c.obj' 'glib/glib@@glib-2.0@sha/gvariantty
peinfo.c.obj' 'glib/glib@@glib-2.0@sha/gvarianttype.c.obj' 'glib/glib@@glib-2.0@sha/gversion.c.obj' 'glib/glib@@glib-2.0@sha/gwakeup.c.obj' 'glib/glib@@glib-2
.0@sha/gprintf.c.obj' 'glib/glib@@glib-2.0@sha/gwin32.c.obj' 'glib/glib@@glib-2.0@sha/gspawn-win32.c.obj' 'glib/glib@@glib-2.0@sha/giowin32.c.obj' 'glib/glib@
@glib-2.0@sha/gthread-win32.c.obj' -flto -Wl,--no-undefined -Wl,--as-needed -Wl,-O1 -shared -Wl,--start-group -Wl,--out-implib=glib/libglib-2.0.dll.a glib/lib
charset/libcharset.a glib/gnulib/libgnulib.a -Wl,-Bsymbolic-functions -lws2_32 -lole32 -lwinmm -lshlwapi /usr/i686-w64-mingw32/lib/libpcre.dll.a -lintl -lws2_
32 -lwinmm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x2940): undefined reference to `_
g_gnulib_vasprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x6b51): undefined reference to `_g_gnulib_sprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x6b8d): undefined reference to `_g_gnulib_sprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x6bd2): undefined reference to `_g_gnulib_sprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x6c05): undefined reference to `_g_gnulib_sprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x6c2a): undefined reference to `_g_gnulib_sprintf'
/usr/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/ld: /tmp/ccNiHBY6.ltrans0.ltrans.o:<artificial>:(.text+0x29f9): undefined reference to `_g_gnulib_vsnprintf'
...

@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).

Could you cleanup the exe files? xan.

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

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 https://gstreamer.freedesktop.org/documentation/installing/building-from-source-using-cerbero.html and they work with msvc https://gstreamer.freedesktop.org/documentation/installing/on-windows.html .lib are generated this way: https://cgit.freedesktop.org/gstreamer/cerbero/tree/cerbero/ide/vs/genlib.py#n33 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

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++.