Search Criteria
Package Details: mingw-w64-glib2 2.82.0-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 |
Upstream URL: | https://gitlab.gnome.org/GNOME/glib |
Keywords: | glib2 gnome gtk gtk2 gtk3 mingw mingw-w64 |
Licenses: | LGPL-2.1-or-later |
Submitter: | brcha |
Maintainer: | Martchus |
Last Packager: | Martchus |
Votes: | 20 |
Popularity: | 0.000000 |
First Submitted: | 2012-06-13 19:15 (UTC) |
Last Updated: | 2024-09-01 17:16 (UTC) |
Dependencies (7)
- mingw-w64-gettextAUR
- mingw-w64-libffiAUR
- mingw-w64-pcre2AUR
- mingw-w64-zlibAUR
- git (git-gitAUR, git-glAUR) (make)
- mingw-w64-mesonAUR (make)
- python-packaging (make)
Required by (28)
- mingw-w64-atk
- mingw-w64-cairo
- mingw-w64-cairo-bootstrap
- 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-gtk2
- mingw-w64-gtk3
- mingw-w64-gtk4
- mingw-w64-harfbuzz
- mingw-w64-json-glib
- mingw-w64-libadwaita
- mingw-w64-libcroco
- mingw-w64-libgtop
- mingw-w64-libnice
- mingw-w64-libsearpc
- mingw-w64-libsmf
- mingw-w64-libsoup
- mingw-w64-libsoup3
- mingw-w64-meanwhile
- mingw-w64-poppler (make)
- mingw-w64-poppler (optional)
- mingw-w64-shared-mime-info-bin
- qemu-guest-agent-windows (make)
Latest Comments
« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »
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)
« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »