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>
When the system supports it (as all Linux kernels ≥ 5.3 should), it’s
preferable to use `pidfd_open()` and `waitid()` to be notified of
child processes exiting or being signalled, rather than installing a
default `SIGCHLD` handler.
A default `SIGCHLD` handler is global, and can never interact well with
other code (from the application or other libraries) which also wants to
install a `SIGCHLD` handler.
This use of `pidfd_open()` is racy (the PID may be reused between
`g_child_watch_source_new()` being called and `pidfd_open()` being
called), so it doesn’t improve behaviour there. For that, we’d need
continuous use of pidfds throughout GLib, from fork/spawn time until
here. See #1866 for that.
The use of `waitid()` to get the process exit status could be expanded
in future to also work for stopped or continued processes (as per #175)
by adding `WSTOPPED | WCONTINUED` into the flags. That’s a behaviour
change which is outside the strict scope of adding pidfd support,
though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1866Fixes: #2216
We have fallback in places for GNU's variadic arguments in macros, and
for static inline functions with variadic arguments as an fallback of
last resort, but going forward we are going to depend on `__VA_ARGS__`
for macros that cannot be re-implemented using a static inline function.
Fixes: #2681
This means we can specify the standard options for testing GLib under
valgrind consistently, so that developers can use `meson test
--setup=valgrind` to run them.
Port the existing valgrind CI to use them (this will not change its
functional behaviour).
Suggested by Marco Trevisan at
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2717#note_1478891.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
intl is complicated to look up. Some of that complexity now resides in
Meson, since 0.59.0, via a `dependency('intl')` lookup, so use that
instead.
The Meson lookup doesn't include all the checks here, but likewise this
meson.build doesn't include all the checks in Meson. Particularly, the
following are different:
- Meson accurately detects support built into libc, even if that
conflicts with an external library version (which should be detected as
broken and thus not-found, but glib does not do so).
The problem here is that depending on which libintl.h header is first
in the search path, the *gettext symbols may be the libc ABI, or they
may be renamed to libintl_*gettext, then additionally take over the
*gettext names via a macro, in order to invoke the external library
version even on systems where there is a libc builtin. This means that
checking for `cc.has_function()` correctly reports that there is such
a function in libc, but that unfortunately does not mean it is usable,
because source code referencing `ngettext` etc. will expect to be
linked to `libintl_ngettext`.
- glib checks whether the found intl requires pthread, rather than
simply trusting the result of `cc.find_library()` for the external
library case.
Do the heavy lifting by using Meson to check for intl, and select the
correct implementation, but do a post-discovery check if the symbol is
linkable both with/without pthread.
The logic is still a bit hairy, and eventually more of the logic could
be moved into Meson. But it's better than before.
Fixes incorrect detection of intl on musl-based systems (which have a
less capable libc intl), when GNU libintl is installed as an external
library.
iconv is complicated to look up. That complexity now resides in
Meson, since 0.60.0, via a `dependency('iconv')` lookup, so use that
instead.
No effort is made to support the old option for which type of iconv to
use. It was a false choice, because if only one was available, then
that's the only one you can use, and if both are available, the external
iconv shadows the builtin one and renders the builtin one unusable,
so there is still only one you can use.
This meant that when configuring glib with -Diconv=libc on systems that
had an external iconv, the configure check would detect a valid libc
iconv, try to use it, and then fail during the build because iconv.h
belongs to the external iconv and generates machine code using the
external iconv ABI, but fails to link to the iconv `find_library()`.
Meson handles this transparently.
Rather than carrying the copylib around inside GLib, which is a pain to
synchronise and affects our code coverage statistics.
This requires updating the CI images to cache the new subproject,
including updating the `cache-subprojects.sh` script to pull in git
submodules.
It also requires adding `gioenumtypes_dep` to be added to the
dependencies list of `libgio`, since it needs to be build before GVDB as
it’s pulled in by the GIO headers which GVDB includes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2603
Atomic APIs provide a way to exchange values only if we compare a value
that is equal to the old value, but not to just exchange the value
returning the old one.
However, compilers provide such built-in functions, so we can use them
to expose such functionality to GLib.
The only drawback is that when using an old version of gcc not providing
atomic APIs to swap values, we need to re-implement it with an
implementation that may not be fully atomic, but that is safe enough.
However this codepath should really not be used currently as gcc
introduced __atomic_exchange_n() at version 4.7.4, so 8 years ago.
Since Meson 0.54.0, `dependency('zlib')` will fallback on systems
without a pkg-config dependency, to a system dependency lookup that
performs the necessary `find_libary('z')` (or MSVC zlib/zlib1) and
`has_header('zlib.h')` checks.
This means all the manual lookups are no longer needed, and a single
dependency lookup covers all cases, and also clarifies the log lookup by
not sometimes listing "not found" a couple times.
With Meson 0.60 (or possibly some earlier versions) we can factor the
checks out as a variable can now be used as an array key. This
simplifies the checks a little, while introducing no functional
differences.
The contents of `g_sizet_compatibility` after this block are identical
with and without the changes applied.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since Meson 0.47, this can be used to check a header with compilation,
rather than just stat. This removes a workaround.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Check the spawn implementation behaviour when the stderr is a
socket (mostly for win32).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
As per meson spec, returncode() produces unspecified data if
compiled() == false. Check compiled() first to avoid relying
upon unspecified data.
In addition, muon -- an implemetation of meson written in C goes
further and forbids returning unspecified data. This is a good
decision, but also makes it harder to support applications which
wrongly use meson API. Therefore, application needs to be fixed.
It is not only shorter than `not meson.is_cross_build() or
meson.has_exe_wrapper()` but also handle the case of cross compiling to
a compatible arch such as building for i386 on an amd64.
Move msvc warnings in meson.build file from line 24 to line 469 to group
them next to gcc/clang warnings. So it is easier to see warnings flags
for all platforms at once.
This reverts commit 4a4d9eb662.
It seems to cause build failures with `VsDevCmd.bat` 2022:
```
..\meson.build:2274:0: ERROR: Command "C:\Program Files\Meson\meson.exe runpython --version" failed with status 2.
```
Revert it for now until this can be fixed in Meson.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2541#note_1410521
It can be treated like any other command, we don't need a full blown
module capable of building extensions just to get an ExternalProgram
executable that can be used to run scripts.
Since find_program has a builtin kwarg for requiring a given version, we
can avoid manually coding some checks and emitting a custom error.
