Search Criteria
Package Details: mingw-w64-glib2 2.72.3-1
Package Actions
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) |
Dependencies (6)
Required by (34)
- mingw-w64-atk
- mingw-w64-cairo
- mingw-w64-cairo-bootstrap
- mingw-w64-ccnet
- mingw-w64-fluidsynth
- mingw-w64-fluidsynth-bin
- mingw-w64-gdk-pixbuf2
- mingw-w64-glib-networking
- mingw-w64-glibmm
- mingw-w64-graphene
- mingw-w64-gstreamer
- mingw-w64-gstreamer-git
- mingw-w64-gtk2
- mingw-w64-gtk3
- mingw-w64-gtk4
- mingw-w64-gts
- mingw-w64-harfbuzz
- mingw-w64-harfbuzz-static
- mingw-w64-json-glib
- mingw-w64-json-glib-bin
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
drakkan commented on 2020-05-19 13:21 (UTC)
OK, I'll add a
NO_EXECUTABLES
env var here too, thanks for the suggestionMartchus 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
: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 wrongstrip
(eg. version from nativebinutils
) could actually lead toarchive 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)
Yes
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 toar
. Do you know how to add additional flags for thear
tool in meson?Or maybe I should use
i686-w64-mingw32-gcc-ar
instead ofi686-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:
mingw-w64-{gcc,binutils}-bin
and I'm usingmingw-w64-{gcc,binutils}
.mingw-w64-headers-bin-5.0.4-1
and I'm usingmingw-w64-headers-5.0.4-2
.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.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:
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 regularglib2
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)
drakkan commented on 2017-02-01 23:30 (UTC)
Martchus commented on 2017-02-01 21:57 (UTC)
drakkan commented on 2017-02-01 21:08 (UTC)
drakkan commented on 2017-01-11 16:48 (UTC)
Martchus commented on 2016-08-17 22:15 (UTC)
Schala commented on 2016-08-17 22:07 (UTC)
Martchus commented on 2016-08-13 14:15 (UTC) (edited on 2016-08-13 14:16 (UTC) by Martchus)
pnyetmja commented on 2015-09-26 13:33 (UTC)
ant32 commented on 2015-09-25 03:12 (UTC)
pnyetmja commented on 2015-09-24 21:39 (UTC)
Schala commented on 2015-09-24 17:55 (UTC)
Schala commented on 2015-09-24 17:53 (UTC)
pnyetmja commented on 2015-09-24 08:46 (UTC)
ant32 commented on 2015-03-04 18:08 (UTC)
Martchus commented on 2015-03-04 17:20 (UTC)
Schala commented on 2015-03-03 23:18 (UTC)
Martchus commented on 2015-03-03 20:07 (UTC)
hanckmann commented on 2015-02-15 18:29 (UTC)
xantares commented on 2014-12-14 18:25 (UTC)
ant32 commented on 2014-12-14 16:49 (UTC)
xantares commented on 2014-11-19 16:57 (UTC)
riguk commented on 2014-11-19 15:03 (UTC)
riguk commented on 2014-11-18 15:52 (UTC)
riguk commented on 2014-11-18 15:36 (UTC)
riguk commented on 2014-11-18 15:10 (UTC)
xantares commented on 2014-11-18 14:04 (UTC)
riguk commented on 2014-11-18 13:31 (UTC)
xantares commented on 2014-11-18 12:33 (UTC)
riguk commented on 2014-11-18 11:23 (UTC)
xantares commented on 2014-11-01 20:10 (UTC)
xantares commented on 2014-11-01 17:24 (UTC)
ant32 commented on 2013-10-28 17:03 (UTC)
ant32 commented on 2013-10-14 23:39 (UTC)
xantares commented on 2013-10-07 17:41 (UTC)
ekpyron commented on 2013-09-06 00:07 (UTC)
ant32 commented on 2013-09-05 23:52 (UTC)
ekpyron commented on 2013-09-05 23:42 (UTC)
Schala commented on 2013-04-17 22:51 (UTC)
brcha commented on 2013-03-15 21:46 (UTC)
Schala commented on 2013-03-15 21:44 (UTC)
brcha commented on 2013-03-15 11:22 (UTC)
Schala commented on 2013-03-15 05:40 (UTC)
brcha commented on 2013-01-22 18:25 (UTC)
Schala commented on 2013-01-21 16:10 (UTC)
entidi commented on 2012-10-11 17:06 (UTC)
svanheulen commented on 2012-08-10 20:48 (UTC)