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.
When working with storage (especially GInputStream or GOutputStream) it
is preferred to use page-aligned buffers so that the operating system
can do page-mapping tricks as the operation passes through the kernel.
Another use case is allocating memory used for vectorised operations,
which must be aligned to specific boundaries.
POSIX and Windows, as well as the C11 specification, provide this kind
of allocator functions, and GLib already makes use of it inside GSlice.
It would be convenient to have a public, portable wrapper that other
projects can use.
Fixes: #2574
