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>
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
Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
This code was skipping fsync on BTRFS because of an old guarantee about
the overwrite-by-rename behavior that no longer holds true. This has
been confirmed by the BTRFS developers to no longer be guaranteed since
Kernel 3.17 (August 2014), but it was guaranteed when this optimization
was first introduced in 2010.
This could result in empty files after crashes in applications using
g_file_set_contents(). Most prominently this might have been the cause
of dconf settings getting lost on BTRFS after crashes due to the
frequency with which such writes can happen in dconf.
See: https://gitlab.gnome.org/GNOME/dconf/-/issues/73
Using ld_flags would work, but that does not propagate ldflags to users
of glib. Meson's dependency() call will propagate apple framework
dependencies to downstream users.
Previously they were only passed to the C compiler, which meant disabled
warnings were still emitted when (for example) including C headers from
C++ and ObjC files.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
It is exactly the same wrap as the one in WrapDB but with a different
name. That fix error when multiple projects uses pcre and they don't
have the same wrap name:
meson.build:1:0: ERROR: Multiple wrap files provide 'libpcre' dependency: pcre.wrap and libpcre.wrap
This is what’s available in the new Debian Stable, so we can expect it
to be available pretty much everywhere.
Subsequent commits will clean up old workarounds.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Include the correct system headers for each test that meson performs.
This allows system capabilities to be detected correctly even if
implicit declaration of functions is considered an error.
This should maintain equivalent functionality, apart from that now you
have to pass `--force-fallback-for libpcre` to `meson configure` in
order to use the subproject; rather than specifying
`-Dinternal_pcre=true` to use the internal copy.
This also fixes#642, as the wrapdb copy of libpcre is version 8.37.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #962Fixes: #642
If libintl is built statically on macOS, linking it requires passing
"-framework CoreFoundation" to satisfy symbol dependencies. Use the
available osx_ldflags already detected earlier in the process.
