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
This test assumes that pcre2 is not provided by a subproject, so force
it to be that. Explicitly allow fallback in the next check (although
it's implied already).
On some systems only `futex_time64` exists (e.g. riscv32) while on
others only `futex` exists (old Linux, 64 bit platforms), so it is
necessary to check for both and try calling both at runtime.
Additionally use the correct `struct timespec` definition. There is not
necessarily any relation between the libc's definition and the kernel's.
Specifically, the libc headers might use 64-bit `time_t` while the kernel
headers use 32-bit `__kernel_old_time_t` on certain systems.
To get around this problem we
a) check if `futex_time64` is available, which only exists on 32-bit
platforms and always uses 64-bit `time_t`.
b) otherwise (or if that returns `ENOSYS`), we call the normal `futex`
syscall with the `struct timespec` used by the kernel, which uses
`__kernel_long_t` for both its fields. We use that instead of
`__kernel_old_time_t` because it is equivalent and available in the
kernel headers for a longer time.
This will be used in upcoming commits to allow the previously-hardcoded
`/run` path to be set at configure time.
Most people will not want to change it from `/run`, even when building
test builds, as otherwise interaction with system mounts and services
will not work.
Inspired by equivalent changes in dbus.git in their commit
ff92efa389a57a5250c6996df6614234d4d462e0.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`join_paths()` automatically drops all preceding path elements if an
argument to it is an absolute path. The `/` is a tidier synonym for
`join_paths()`.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This reverts commit 91f14cd058.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
This reverts commit 756b424cce.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Meson now uses find_program() to get glib-mkenum from glib instead of
from system. That was already fixed at least in >=0.60 which is our
current minimum requirement.
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
We need to ensure that all the expected macros and utilities are working
with all the supported C standards, so just repeat the tests with all
the ones the compiler supports.
It was previously only enabled (by default) on macOS, which led to
code being committed which triggered warnings, as that CI job is not
always run.
Avoid that risk by always enabling the warning.
The reasoning for using this warning is that explicit initialisation is
clearer than implicit. We also want to support GLib’s public headers
being used in projects which build with
`-Werror=missing-field-initializers`, but can’t easily enable the
warning for our public headers but not our internal code. So enable it
everywhere.
Make it a warning rather than an error, as there’s a risk that system
header changes will trigger it in distro release builds, which would
cause false build failures. By making it a warning, GLib developers can
build with `-Werror` and promote it to an error, while distros can
choose not to.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2812
It should be enabled in all builds, not just CI builds. Otherwise
developers might miss it locally.
This updates commit f11b96f255.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Allow one to override the invalid parameter handler if we have the
following items:
* _set_invalid_parameter_hander() or
_set_thread_local_parameter_handler()
* _CrtSetReportMode() as a function or macro
Currently, we are doing this on Visual Studio to allow GSpawn to work on
Windows as well as having the log writer support color output, as we
might be passing in file descriptors that are invalid, which will cause
the CRT to abort unless the default invalid parameter handler is
overridden.
Given that it can be computed using an error-prone strings comparisons it
is better to provide a variable everywhere, so that we don't have the
risk of comparing values that are always false.
We have tests that are failing in some environments, but it's
difficult to handle them because:
- for some environments we just allow all the tests to fail: DANGEROUS
- when we don't allow failures we have flacky tests: A CI pain
So, to avoid this and ensure that:
- New failing tests are tracked in all platforms
- gitlab integration on tests reports is working
- coverage is reported also for failing tests
Add support for `can_fail` keyword on tests that would mark the test as
part of the `failing` test suite.
Not adding the suite directly when defining the tests as this is
definitely simpler and allows to define conditions more clearly (see next
commits).
Now, add a default test setup that does not run the failing and flaky tests
by default (not to bother distributors with testing well-known issues) and
eventually run all the tests in CI:
- Non-flaky tests cannot fail in all platforms
- Failing and Flaky tests can fail
In both cases we save the test reports so that gitlab integration is
preserved.
C99 guarantees that va_copy() exists, so use it, instead of probing
for __va_copy(), va_copy(), or a reimplementation from first principles.
Signed-off-by: Simon McVittie <smcv@collabora.com>
There is currently no `dllimport` attribute on any of our function,
which prevents MSVC to optimize function calls.
To fix that issue, we need to redeclare all our visibility macros for
each of our libraries, because when compiling e.g. GIO code, we need
dllimport in GLIB headers and dllexport in GIO headers. That means they
cannot use the same GLIB_AVAILABLE_* macro.
Since that's a lot of boilerplate to copy/paste after each version bump,
this MR generate all those macros using a python script.
Also simplify the meson side by using `gnu_symbol_visibility : 'hidden'`
keyword argument instead of passing the cflag manually.
This leaves only API index to add manually into glib-docs.xml when
bumping GLib version. That file cannot be generated because Meson does
not allow passing a buit file to gnome.gtkdoc()'s main_xml kwarg
unfortunately.
We require C99 now, and this warning was added for strict adherence to
C89 because GCC allowed mixed declarations in gnu89 as a GCC
extension. Let's get rid of this.
Commit 4a4d9eb662 initially switched Meson to find the python
program using find_program('python3'). Sadly that caused a
regression, since in some cases with MSVC it would fallback to
'meson.exe runpython', which is undesired.
However, that particular code was reverted back to an also
undesired lookup method, find_installation('python3'). This
way of finding python also breaks on Windows + MSVC, in particular
when setting it up as follows:
```
winget install python
winget install meson
```
This fails building GLib with:
> python3 not found
Fix that by not passing any argument to find_installation(), which
lets Meson figure it all out by itself.
The tests that functionally rely on G_ENABLE_DIAGNOSTIC=1 still set it
explicitly, so that they will behave as expected when run as
installed-tests or manually.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We've various macros definitions that are depending using C++ features
that may not work in all the standard versions, so recompile the cxx
tests that we have in all the ones we want to support.
glib_debug is an auto option. This is clever because it allows us to
guess the best default based on the build type, while also allowing an
easy way to override if the guess is not good. Sadly, the attempt to
guess based on the build type does not work well. For example, it
considers debugoptimized builds to be debug builds, but despite the
name, it is definitely a release build type (except on Windows, which
we'll ignore here). The minsize build type has the exact same problem.
The debug option is true for both build types, but this only controls
whether debuginfo is enabled, not whether debug extras are enabled.
The plain build type has a different problem: debug is off, but the
optimization option is off too, even though plain builds are distro
builds are will almost always use optimization.
I've outlined an argument for why we should make these changes here:
https://blogs.gnome.org/mcatanzaro/2022/07/15/best-practices-for-build-options/
Specifically, Rule 4 shows all the build types and whether they
correspond to release builds or debug builds. Rule 6 argues that we
should provide good defaults for plain builds.
This is an internal helper executable, which users shouldn't invoke
directly (see glib#1633).
When building for a single-architecture distribution, we can install
it as ${libexecdir}/gio-launch-desktop.
When building for a multiarch distribution, installing it into an
architecture-specific location and packaging it alongside the GLib
library avoids the problem discussed in glib#1633 where it would either
cause a circular dependency between the GLib library and a common
cross-architecture package (libglib2.0-bin in Debian), or require a
separate package just to contain gio-launch-desktop, or cause different
architectures' copies to overwrite each other.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In Debian-style multiarch (libdir = lib/x86_64-linux-gnu or similar),
Red-Hat-style multilib (libdir = lib64 or lib) and Arch-style multilib
(libdir = lib or lib32), we have to run a separate version of
gio-querymodules to discover 32- or 64-bit modules on x86. Installing
modules in the directory used for each word size needs to trigger
recompilation of the correct modules list.
Debian, Fedora and Arch currently all have patches to facilitate this:
Debian moves gio-querymodules into ${libdir}/glib-2.0 and provides a
compat symlink in ${bindir}, while Fedora and Arch rename one or both
of the gio-querymodules executables to give it a -32 or -64 suffix.
We can avoid the need for these patches by making this a build option.
Doing this upstream has the advantage that the pkg-config metadata for
each architecture points to the correct executable and is in sync with
reality.
I'm using Debian's installation scheme with a separate directory here,
because the word-size suffix used in Fedora and Arch only works for the
common case of 32- and 64-bit multilib, and does not cover scenarios
where there can be more than one ABI with the same word size, such as
multiarch cross-compilation or alternative ABIs like x32.
Now that we have this infrastructure, it's also convenient to use it for
glib-compile-schemas. This works with /usr/share, so it only needs to
be run for one architecture (typically the system's primary
architecture), but using /usr/bin/glib-compile-schemas for the trigger
would result in either primary and secondary architectures trying to
overwrite each other's /usr/bin/glib-compile-schemas binaries, or a
circular dependency (the GLib library would have to depend on a
common package that contains glib-compile-schemas, but
glib-compile-schemas depends on the GLib library). Installing a
glib-compile-schemas binary in an architecture-specific location
alongside each GLib library bypasses this problem.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't need a cpp toolchain for building glib so lets just
automatically disable tests requiring one when not available.
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
This can catch the wrong pointer being passed to a function argument (in
some cases), with few false positives.
Spotted while testing !2529.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
