Package Details: mingw-w64-glib2 2.66.7-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: 19
Popularity: 0.000027
First Submitted: 2012-06-13 19:15
Last Updated: 2021-02-19 07:29

Latest Comments

1 2 3 4 5 6 ... Next › Last »

drakkan commented on 2021-04-19 20:22

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

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

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

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

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

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

drakkan commented on 2020-05-19 20:41

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

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

Martchus commented on 2020-05-19 12:55

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

@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!