If glib and PCRE2 are both built for Windows as subprojects of a parent
project, cc.links() will fail because PCRE2 hasn't been built yet when
glib is being configured:
subprojects/glib-2.78.0/meson.build:2109:20: ERROR: Dependencies must be external dependencies
609d58beea changed the detection logic to avoid cc.links() in this
case, but dd5683ce64 broke it again. PCRE2 detection could use a
broader cleanup, but for now, make the minimum change to fix this case.
use_pcre2_static_flag ends up set to false, matching the behavior of
609d58beea.
Fixes: dd5683ce64 ("meson: Allow fallback & static build of pcre subproject")
GCC >= 4.7 and clang >= 12 don't need it. It should be left to the user
to decide what ABI convention should be used, and it creates some issues
with some tools to have this flag in cflags.
We leave the flag for now, but print a warning at compile time so people
get a chance to change their build system before we drop it from glib.pc
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This reverts commit 252bbcd207.
After further discussion in !3511, we’ve decided that there are risks
associated with this change, and it’s not the best way of addressing the
original problem.
The original motivation for the change turned out to be that
`-mms-bitfields` was not handled by `windres`, which was receiving it
from `pkg-config --cflags glib-2.0` in some projects. However, if
`windres` is claiming to accept CFLAGS then it should accept (and
ignore) `-mms-bitfields`, since the `-m` family of options are defined
in `man gcc`, just like `-I`, `-D`, etc.
There is some question that there might still be third party projects
which are built with an old enough compiler that `-mms-bitfields` is not
the compiler default. For that reason, we should either still continue
to specify `-mms-bitfields` in the `.pc` file, or add a test to assert
that third party projects are always compiled with `-mms-bitfields` set.
But adding a new test for all third-party compilations is risky (if we
get it wrong, things will break; and it’s a test which may behave
differently on different platforms), so it seems safer to just keep
`-mms-bitfields` in `.pc` for now.
Once all compilers which we require specify `-mms-bitfields` by default,
we can finally drop this flag (without adding a test for third-party
compilations).
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511
Otherwise, crashing tests like assert-msg-test will still report to
pipe-based crash reporting frameworks like systemd-coredump, even though
the RLIMIT_CORE limit is zero.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gobject-introspection is currently assuming glib subproject
is in unversioned, but gstreamer uses a versioned directory, eg:
subprojects/glib-2.74.1 instead of subprojects/glib
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
Using `allow_fallback: false` on the first check for libpcre
was unnecessary, as `required: false` already disables using
fallbacks. `allow_fallback: false` meant that
`--force-fallback-for` couldn’t work. This commit fixes that.
Also allow the fallback libpcre to be built statically so it
can be linked into GLib.
Helps: #3025
This was originally removed in !2734 but still appears to be required for
some MinGW setups, such as the `x86_64-w64-mingw32.static` target in
[mxe](https://github.com/mxe/mxe).
Currently, this configuration fails the libintl internal assert on line
2128, as on this platform `ngettext()` is only found inside libiconv.
This commit will look up iconv potentially twice, once as `libiconv` and
potentially once as `libintl_iconv`. This is what the code did before
!2734 landed, so it’s known to work reliably on a number of platforms.
This allows the `g_free()` wrapper introduced in the previous commit to
only be defined if `free_sized()` is actually available to improve
performance.
This avoids passing an allocation size to every `g_free()` call if it’s
not going to be used, saving a register store instruction each time.
Suggested by Marco Trevisan in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3252#note_1660032
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When `copy_file_range()` support was added, I used the definition of
`copy_file_range()` from Linux, which uses `loff_t` to abstract the
different `off*_t` types.
`loff_t` doesn’t exist on FreeBSD, so this doesn’t compile, and was
caught in subsequent asynchronous CI.
Define `loff_t` with a fallback value if it’s not defined, which should
fix this and other uses of `loff_t` in `gfile.c` (for example, if
FreeBSD ever starts declaring `splice()`).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/2812302
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it can’t be used in all situations, it is a little bit faster than
`splice()` in some situations, basically if the file system supports
copy on write. In other situations it’s no slower than `splice()`.
See `man copy_file_range` for the situations where it doesn’t work. In
all of these situations, it will return an error, and the GLib code will
fall through and try the existing `splice()` copy code instead.
From my testing of `time gio copy A B` with a 9GB file, the `splice()`
code path takes 22s, and the `copy_file_range()` code path takes 20s.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2863
When cross-building with a non-Linux target, linux/netlink.h will not
actually be buildable, even if distributions typically put it in
/usr/include and thus exposed to the cross-compiler.
Various projects are running tests under valgrind, and they are using
the GLib suppresions to avoid false-positive results.
While this is stored in a well-known path for some years, and easy to
figure out from the GLib prefix, it's better to expose it through a
proper pkgconfig variable so that it's easy to get it from any build
system.
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
proxy-libintl defines ngettext() as a define in the header that points
to the actual symbol in the library which is g_libintl_ngettext().
Same with bind_textdomain_codeset().
If we are sorting something that is a multiple of sizeof(void*), we have
to ensure that we swap one pointer at a time since swapping using
sub-pointer-size stores invalidate the pointers (pointers have a hidden
validity tags that is invalidated when performing non-monotonic
operations such as storing only part of the pointers).
While touching this code also use G_ALIGNOF() instead of a macro that
is generated at configure time.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2842
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
Setting the main thread's scheduler settings is not reliably possible,
especially not if SELinux or similar mechanisms are used to limit what
can be done.
As such, get rid of all the complicated code that tried to do this
better and use a separate thread for spawning threads for the global
shared thread pool. These will always inherit the priority of the main
thread (or rather the thread that created the first shared thread pool).
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2769
If proxy-libintl has already been configured before we get to glib, we
will pick that up in dependency('intl'), which then does compiler
checks on it. This was written to assume that the first check will not
find a subproject for libintl, so force it with allow_fallback: false.
Also update the proxy-libintl wrap file and get rid of the explicit
subproject() call.
Reported by Benjamin Gilbert at
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3172
