Package Details: mingw-w64-glib2 2.72.3-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-glib2.git (read-only, click to copy)
Package Base: mingw-w64-glib2
Description: Low level core library (mingw-w64)
Upstream URL: https://wiki.gnome.org/Projects/GLib
Keywords: glib2 gnome gtk gtk2 gtk3 mingw mingw-w64
Licenses: LGPL2.1
Submitter: brcha
Maintainer: drakkan
Last Packager: drakkan
Votes: 21
Popularity: 0.004777
First Submitted: 2012-06-13 19:15 (UTC)
Last Updated: 2022-07-10 07:55 (UTC)

Latest Comments

drakkan commented on 2021-06-01 14:09 (UTC)

yes, I just tested using gcc 11 and now it builds on i686 too

Martchus commented on 2021-06-01 13:52 (UTC)

So now (after updating certain dependencies) it just works? (I'm just curious what caused the previous problem.)

drakkan commented on 2021-04-19 20:22 (UTC) (edited on 2021-04-19 20:23 (UTC) by drakkan)

I think it is something in our toolchain, we use the same patches as fedora and glib2 build there, while on Arch it doesn't build for i686 while it works for x86_64. It seems something in libuuid but I'm not sure

Martchus commented on 2021-04-19 12:14 (UTC) (edited on 2021-04-19 12:15 (UTC) by Martchus)

The diff is huge: https://github.com/GNOME/glib/compare/2.66.7...2.68.1

I checked it out a little bit (locally) but it is just too much to find the possible culprit. Maybe it is nevertheless worth reporting an upstream bug? Could be either a glib2 bug or a mingw-w64 bug.

However, it looks like MSYS2 could upgrade: https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-glib2

drakkan commented on 2021-04-19 11:04 (UTC)

Hi guys,

I'm having issues updating to glib 2.68.1, here is the diff. It builds fine on x86_64-w64-mingw32 but if fails on i686-w64-mingw32 with this link error. Do you have ideas? Thank your

Martchus commented on 2020-10-20 22:40 (UTC)

I've just restarted the build and now it works. Not sure why it previously failed. I suppose it is not worth investigating this further.

drakkan commented on 2020-10-20 20:47 (UTC) (edited on 2020-10-20 20:48 (UTC) by drakkan)

it is strange, it builds and links fine for me. I'll try to better investigate tomorrow

Martchus commented on 2020-10-20 20:30 (UTC)

Unfortunately I've got tons of linker errors: https://paste.opensuse.org/33853248

drakkan commented on 2020-05-19 20:41 (UTC)

done, it isn't a great gain

Total Installed Size:  78.59 MiB
Net Upgrade Size:      -0.63 MiB

drakkan commented on 2020-05-19 13:21 (UTC)

OK, I'll add a NO_EXECUTABLES env var here too, thanks for the suggestion

Martchus commented on 2020-05-19 12:55 (UTC) (edited on 2020-05-19 13:57 (UTC) by Martchus)

I don't need the executables of this particular package so the decision isn't very important to me. Generally it seems wrong to delete them just to save a few KiB on my floppy disk because they might be useful at some point after all. So far I've just ignored executables I didn't need and I don't see any problem with that.

By the way, the whole "let's not blindly delete all executables" idea came up when I started to use x264, x265 and ffmpeg. The executables contained by these packages are indeed useful to have. Even if ffmpeg isn't used directly after all it can be quite useful for checking quickly whether the libraries work. Maybe the same applies to other packages as well.

So from my point of view we should not have a general "keep EXEs" or "delete EXEs" rule which should be applied to all packages. Since EXEs can be useful I'd like to keep them in doubt but if really nobody uses them (which might be the case in this package) I have nothing against deleting them. By the way, the Qt 5 packages use the NO_EXECUTABLES environment variable to decide whether to keep EXEs so that's also an option.

If you decide to remove EXEs in your packages, please do not bump the pkgrel in this case. I find it unnecessary to rebuild packages just to remove EXEs.

drakkan commented on 2020-05-19 11:19 (UTC)

@xantares, no problem to remove the exes, but are we sure that noone need them? I use glib as gstreamer dependency so I don't need exes but executables like glib-compile-resources could be useful. @Martchus, @other, do you agree to remove exes from this PKGBUILD (and others that I maintain?), thanks!

xantares commented on 2020-05-19 08:00 (UTC)

ok. could we remove the exes please ?

Martchus commented on 2020-05-18 09:00 (UTC)

I don't have a problem with using Git. Once one cloned it one just needs to fetch what's new so it isn't that bad and might even speed up subsequent updates.

And yes, if nothing speaks against it, it makes sense to follow what the official/regular PKGBUILDs do.

drakkan commented on 2020-05-18 07:16 (UTC) (edited on 2020-05-18 07:17 (UTC) by drakkan)

@xantares, git clones are used in the PKGBUILD in the official Arch Linux repo too. Aren't we supposed to be as close as possible to the PKGs in the official repos?

xantares commented on 2020-05-18 06:52 (UTC)

can the source be changed to use the tarball, git clone takes forever:

https://download.gnome.org/sources/glib/2.64/

drakkan commented on 2018-09-23 18:00 (UTC)

@Martchus thanks!

I have some more changes to test

http://94.177.162.225/temp/mingw-w64-glib2/PKGBUILD http://94.177.162.225/temp/mingw-w64-glib2/0001-Use-CreateFile-on-Win32-to-make-sure-g_unlink-always.patch http://94.177.162.225/temp/mingw-w64-glib2/0001-win32-Make-the-static-build-work-with-MinGW-when-pos.patch

this PKGBUULD compiles, but I would like to do some more testing before push upstream

Martchus commented on 2018-09-23 16:58 (UTC)

I've rebuilt the package (using this PKGBUILD). Let's see whether Qt 5 builds now. As soon as mingw-w64-qt5-declarative appears in my repo you can assume it worked :-)

drakkan commented on 2018-09-23 07:34 (UTC) (edited on 2018-09-23 07:36 (UTC) by drakkan)

@Martchus

this is a meson bug

https://github.com/mesonbuild/meson/pull/3939

for now probably we need to use the same hack and remove -lcharset and -lgiowin32 too. I have no time to test today, I'll check this during the next week, thanks for reporting and sorry for the annoyance

Martchus commented on 2018-09-21 09:06 (UTC)

Unfortunately there's another issue. The pkg-config file contains -lgnulib which is not correct since in our configuration that library is not used.

See grep -R gnulib /usr/{i686,x86_64}-w64-mingw32/lib/pkgconfig:

/usr/i686-w64-mingw32/lib/pkgconfig/glib-2.0.pc:Libs.private: -L${libdir} -lcharset -lgnulib -lws2_32 -lwinmm -lws2_32 -lole32 -lwinmm -lshlwapi
/usr/x86_64-w64-mingw32/lib/pkgconfig/glib-2.0.pc:Libs.private: -L${libdir} -lcharset -lgnulib -lws2_32 -lwinmm -lws2_32 -lole32 -lwinmm -lshlwapi

It leads to the error reported here: https://aur.archlinux.org/packages/mingw-w64-qt5-declarative

drakkan commented on 2018-09-06 21:41 (UTC)

reported upstream

https://github.com/mesonbuild/meson/issues/4138

thanks for testing the updated version and sorry for the annoyance

Martchus commented on 2018-09-06 21:16 (UTC)

Thanks for your help, too! Just running ranlib after the build is a workaround indeed. But I'd also say meson should take care of it.

I also tested it. My statically linked Qt Widgets app compiles and runs again :-)

drakkan commented on 2018-09-06 21:00 (UTC)

can you please manually run ranlib or try the latest PKGBUILD?

If it works for you I'll report upstream since it seems a meson issue, thanks for your patience

Martchus commented on 2018-09-06 19:41 (UTC) (edited on 2018-09-06 19:46 (UTC) by Martchus)

Now I tried to link a Qt application against the static library but it fails with /usr/lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/lib/libglib-2.0.a: error adding symbols: archive has no index; run ranlib to add one.

Note that I've picked up your changes in mingw-w64-meson to use $_arch-gcc-ranlib as well and rebuilt this package using it. I also didn't get any suspicious error messages during the build anymore.

However, it strips the library: Stripping target 'glib/libglib-2.0.a' - This shouldn't be a problem, but using the wrong strip (eg. version from native binutils) could actually lead to archive has no index.

Any ideas? You said that you were able to link against the static library so maybe I'm doing something wrong. But which packages using the static lib did you build? Just because I don't think there are no such packages in the AUR. (The package I'm testing with is https://github.com/Martchus/PKGBUILDs/blob/master/passwordmanager/mingw-w64-static/PKGBUILD.)

drakkan commented on 2018-09-03 16:09 (UTC) (edited on 2018-09-03 16:12 (UTC) by drakkan)

I noted the static libraries size increase, it should be normal when using link time optimizations. Anyway I builded several packages that statically link glib and they compile fine. Anyway if the size is a big concern I can remove lto from meson, I'm open to discussion, lto is used in the meson linux PKGBUILD too.

Thanks for your investigations!

Martchus commented on 2018-09-03 15:21 (UTC)

Seems like enabling LTO causes the static libraries to be very big. Additionally, I hope using those static libraries later on won't be problematic.

Martchus commented on 2018-09-03 09:29 (UTC) (edited on 2018-09-03 09:32 (UTC) by Martchus)

Does the autotools version work for you?

Yes

In meson wrapper there is the option -D b_lto=true

I can test that later. Maybe LTO is the cause. The warnings i686-w64-mingw32-ar: glib/glib@@glib-2.0@sha/glist.c.obj: plugin needed to handle lto object are also pointing in that direction. Likely I just have to pass the path of the plugin to ar. Do you know how to add additional flags for the ar tool in meson?

Or maybe I should use i686-w64-mingw32-gcc-ar instead of i686-w64-mingw32-ar. Not sure what the difference is but it could make a difference.

drakkan commented on 2018-09-02 21:34 (UTC) (edited on 2018-09-02 21:41 (UTC) by drakkan)

I'll try to use mingw-w64-{gcc,binutils} too.

Does the autotools version work for you?

In meson wrapper there is the option -D b_lto=true

https://aur.archlinux.org/cgit/aur.git/tree/meson-mingw-wrapper?h=mingw-w64-meson#n34

does something change if you remove this option?

Martchus commented on 2018-09-02 20:52 (UTC) (edited on 2018-09-02 20:58 (UTC) by Martchus)

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.

drakkan commented on 2018-09-02 14:38 (UTC) (edited on 2018-09-02 14:40 (UTC) by drakkan)

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!

Martchus commented on 2018-09-02 13:49 (UTC)

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

drakkan commented on 2018-09-02 13:24 (UTC) (edited on 2018-09-02 13:28 (UTC) by drakkan)

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?

Martchus commented on 2018-09-02 12:55 (UTC) (edited on 2018-09-02 12:56 (UTC) by Martchus)

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

Martchus commented on 2018-01-31 20:22 (UTC) (edited on 2018-01-31 20:22 (UTC) by Martchus)

@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 (UTC)

Could you cleanup the exe files? xan.

lantw44 commented on 2017-02-26 06:24 (UTC)

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 (UTC)

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

Martchus commented on 2017-02-01 21:57 (UTC)

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 (UTC)

please add import library for linking in Visual Studio, patch here: http://195.250.34.59/temp/0001-add-split-package-for-import-lib.patch 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 (UTC)

Can you please apply the following patch? https://cgit.freedesktop.org/gstreamer/cerbero/tree/recipes/glib/0017-GSocket-Fix-race-conditions-on-Win32-if-multiple-thr.patch

Martchus commented on 2016-08-17 22:15 (UTC)

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

Schala commented on 2016-08-17 22:07 (UTC)

ack, forgot the last part -_-

Martchus commented on 2016-08-13 14:15 (UTC) (edited on 2016-08-13 14:16 (UTC) by Martchus)

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: https://github.com/Martchus/PKGBUILDs/blob/master/glib2/mingw-w64/use-pkgconfig-file-for-intl.patch This is because the bug pnyetmja already mentioned: https://github.com/Alexpux/MINGW-packages/issues/744 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 (UTC)

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

ant32 commented on 2015-09-25 03:12 (UTC)

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 /usr/x86_64-w64-mingw32/lib/qt/mkspecs/win32-g++/qmake.conf 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 (UTC)

I've installed packages from this repo http://downloads.sourceforge.net/project/mingw-w64-archlinux/$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?

Schala commented on 2015-09-24 17:55 (UTC)

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 (UTC)

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

pnyetmja commented on 2015-09-24 08:46 (UTC)

Undefined reference error when statically linking with mingw-w64-qt5-base-static libs https://github.com/Alexpux/MINGW-packages/issues/744 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 (UTC)

@Infinity Schala is probably trying to build 2.42.2 According to https://wiki.archlinux.org/index.php/MinGW_package_guidelines 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 https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-glib2/0027-no_sys_if_nametoindex.patch and you don't need that flag

Martchus commented on 2015-03-04 17:20 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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. (http://www.gnu.org/software/gettext/gettext.html ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build mingw-w64-glib2.

xantares commented on 2014-12-14 18:25 (UTC)

yep, should makedepend on mingw-w64-configure instead of mingw-w64-gcc xan.

ant32 commented on 2014-12-14 16:49 (UTC)

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

xantares commented on 2014-11-19 16:57 (UTC)

hi, 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. xan.

riguk commented on 2014-11-19 15:03 (UTC)

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 (UTC)

by the way should G_OS_WIN32 be set when using mingw-64 ? from configure.ac: g_pid_type="$glib_pid_type" case $host in *-*-cygwin*) 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" ;; esac it seems there is more than one way to solve this.

riguk commented on 2014-11-18 15:36 (UTC)

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) { .... } #define HAVE_IF_NAMETOINDEX 1 #endif 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 (UTC)

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" config.h.in --> your sed NOCONFIGURE=1 ./autogen.sh } but it still doest not work and i really think this is because autogen.sh create config.h.in 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 (UTC)

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

riguk commented on 2014-11-18 13:31 (UTC)

thanks, i managed by my own to create the patch and made it works then i discovered that config.h.in was generated as stated in the first lines of the file --' /* config.h.in. Generated from configure.ac 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 (UTC)

how to create a patch ? read this: https://wiki.archlinux.org/index.php/Patching_in_ABS or you just use the previous sed I gave previously, read the fraking comments. xan.

riguk commented on 2014-11-18 11:23 (UTC)

hi, 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 if_indextoname...no 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 configure.ac:1033 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/config.h.in.orig 2014-11-18 11:37:41.519237600 +0100 +++ glib-2.42.0/config.h.in 2014-11-18 11:38:01.253364100 +0100 @@ -193,7 +193,7 @@ #undef HAVE_IF_INDEXTONAME /* Define to 1 if you have the `if_nametoindex' function. */ -#undef HAVE_IF_NAMETOINDEX +#define HAVE_IF_NAMETOINDEX 1 /* Define to 1 if you have the `inotify_init1' function. */ #undef HAVE_INOTIFY_INIT1 but i can't manage to get it work! does somebody can explain to me how to create a patch for makepkg-minggw ? riguk.

xantares commented on 2014-11-01 20:10 (UTC)

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" config.h.in

xantares commented on 2014-11-01 17:24 (UTC)

hello, the builds fails, I suspect the new mingw-crt 3.3.0 provides if_nametoindex (netioapi.h) and it's not properly detected: https://gist.github.com/xantares/ad9bcfa496ca46ebe0b0 xan.

ant32 commented on 2013-10-28 17:03 (UTC)

Fixed src tarball and updated to 2.38.1 https://dl.dropboxusercontent.com/u/33784287/aur/mingw-w64-glib2-2.38.1-1.src.tar.gz and PKGBUILD https://github.com/ant32/pkgbuild/tree/master/mingw-w64-glib2 View Changes https://github.com/ant32/pkgbuild/commits/master/mingw-w64-glib2 This will be used in the mingw-w64 repo https://sourceforge.net/p/mingw-w64-archlinux/wiki

ant32 commented on 2013-10-14 23:39 (UTC)

Updated src tarball to 2.38.0 https://dl.dropboxusercontent.com/u/33784287/aur/mingw-w64-glib2-2.38.0-1.src.tar.gz and PKGBUILD & patches https://github.com/ant32/pkgbuild/tree/master/mingw-w64-glib2 View Changes https://github.com/ant32/pkgbuild/commits/master/mingw-w64-glib2

xantares commented on 2013-10-07 17:41 (UTC)

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

ekpyron commented on 2013-09-06 00:07 (UTC)

@ant32 http://userpage.fu-berlin.de/mokaga/mingw-w64-glib2-2.37.7-1.src.tar.gz This tarball at least works for me.

ant32 commented on 2013-09-05 23:52 (UTC)

@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 (UTC)

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 (UTC)

Sounds reasonable I guess

brcha commented on 2013-03-15 21:46 (UTC)

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

Schala commented on 2013-03-15 21:44 (UTC)

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

brcha commented on 2013-03-15 11:22 (UTC)

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 (UTC)

pacman -Qs mingw-w64: http://pastebin.com/r9dDhg2Q build log: http://pastebin.com/HtntcSbS

brcha commented on 2013-01-22 18:25 (UTC)

@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 (UTC)

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 (UTC)

0001-win32-fix-build-after-bug-674452.patch is no more needed (commit af3b167). A couple of additional patches should be applied (http://pkgs.fedoraproject.org/cgit/mingw-glib2.git/tree/).

svanheulen commented on 2012-08-10 20:48 (UTC)

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