Previously, when cleaning up the temporary directory tree created by
passing G_TEST_OPTION_ISOLATE_DIRS, any symbolic links in that tree
would be followed recursively. If the test case has created a symbolic
link in its temporary directory to a directory outside that tree, this
could lead to unexpected data loss; in particular, if the test case
author has (unwisely) created a symbolic link to /, they could lose all
data on the system.
On systems that have the ftw.h header, replace the current rm_rf()
implementation with one that uses nftw() to perform a depth-first
traversal (FTW_DEPTH) without following symbolic links (FTW_PHYS), and
without crossing mount points (FTW_MOUNT) in case a test has mounted
some other filesystem in the temporary directory.
The callback logs any error to the standard error stream, but returns 0
rather than -1 to allow nftw() to keep walking the tree rather than
terminating immediately. Suppose we are trying to clean up the following
tree:
tmpdir/
a/
f/ (directory not readable for some reason)
g/
p
b/
c
d
Since tmpdir/a/f is not readable, we can expect to fail to delete
tmpdir/a/f, tmpdir/a and tmpdir; but it is preferable to (attempt) to
delete the rest of the tree rather than failing outright. The cost is
that three errors will be logged (for tmpdir/a/f, tmpdir/a and tmpdir).
nftw() is part of POSIX.1-2001, SUSv1, and glibc ≥ 2.1, so should be
available on effectively every platform except Windows. (And Windows
does not enable symbolic links by default so the developer error is less
likely to occur there.)
The macOS ftw(3) manpage says:
> These functions are provided for compatibility with legacy code. New
> code should use the fts(3) functions.
fts(3) does not seem to be part of any standard, but it does seem to be
equally widely supported. The Linux manpages do not indicate that
nftw() is deprecated.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/3290
Now systemtap can be enabled by default in distros that use
-Dauto_features=enabled or for developers who already have systemtap
installed, while it's still disabled for developers who do not have
systemtap installed. See #3354
Now dtrace can be enabled by default in distros that use
-Dauto_features=enabled or for developers who already have dtrace
installed, while it's still disabled for developers who do not have
dtrace installed. See #3354
It's an array containing the list of sanitizers in use, normally it
contains a value, but in some cases may have more than one (e.g.
'address' and 'undefined').
And so use it to avoid repeated checks
Some architecture such as sparc and some flavors of arm needs -latomic
to avoid the following build failure:
gthread-posix.c:(.text+0xda8): undefined reference to `__atomic_compare_exchange_4'
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
This enables `NULL` pointer dereference checking in the compiler. This
isn’t as good as static analysis, but it should hopefully catch some
simple errors without too high a false positive rate.
If the false positive rate is too high to be useful, we can always
disable it again.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #1767
The python interpreter found by `/usr/bin/env python3` is not
necessarily the same installation as the one that's found by meson's
`pymod.find_installation('python')`. This means that even though meson
is checking that the python installation it found includes the
'packaging' module, the scripts might not have access to that module
when run.
For distribution packaging, it's usually desirable to have python script
interpreters be fully specified paths, rather than use `/usr/bin/env`,
to ensure the scripts run using the expected python installation (i.e.
the one where the python 'packaging' dependency is installed).
The easiest way to fix this is to set the script interpreter to the
`full_path()` of the python interpreter found by meson. The specific
python interpreter that will be used can be selected through the use of
a meson machine file by overriding the "python" program. Many
distributions already have this set up using meson packaging helpers.
If our GPollFunc is set to g_poll() then we can optionally use a poll()
alternative with higher precision. ppoll() provides poll() equivalence
but with timeouts in nanoseconds.
With more precise polling timouts, frame clocks and other timing sensitive
APIs are not restricted to a minimum of 1 millisecond timeout.
This will make it easier and more obvious for developers to run them
locally: I'm sure I'm not the only developer who had assumed that
`.gitlab-ci/` is private to the CI environment and inappropriate (or
perhaps even destructive) to run on a developer/user system.
The lint checks are automatically skipped (with TAP SKIP syntax) if we
are not in a git checkout, or if git or the lint tool is missing. They
can also be disabled explicitly with `meson test --no-suite=lint`,
which downstream distributions will probably want to do.
By default, most lint checks are reported as an "expected failure"
(with TAP TODO syntax) rather than a hard failure, because they do not
indicate a functional problem with GLib and there is a tendency for
lint tools to introduce additional checks or become more strict over
time. Developers can override this by configuring with `-Dwerror=true`
(which also makes compiler warnings into fatal errors), or by running
the test suite like `LINT_WARNINGS_ARE_ERRORS=1 meson test --suite=lint`.
One exception to this is tests/check-missing-install-tag.py, which is
checking a functionally significant feature of our build system, and
seems like it is unlikely to have false positives: if that one fails,
it is reported as a hard failure.
run-style-check-diff.sh and run-check-todos.sh are not currently given
this treatment, because they require search-common-ancestor.sh, which
uses Gitlab-CI-specific information to find out which commits are in-scope
for checking.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is another way to get the file system type from `statvfs()`, newly
added in glibc 2.39
(https://lwn.net/ml/libc-alpha/38790850.J2Yia2DhmK@pinacolada/).
This hasn’t been tested with glibc 2.39 as I don’t have it, but the
change seems fairly straightforward.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The previous commit enabled the `/run/mount/utab` monitoring. The problem
is that the `mount-changed` signal can be emitted twice for one mount. One
for the `/proc/mounts` file change and another one for the `/run/media/utab`
file change. This is still not ideal because e.g. the `GMount` objects for
mounts with the `x-gvfs-hide` option are added and immediately removed.
Let's enable the `mnt_monitor_veil_kernel` option to avoid this.
Related: https://github.com/util-linux/util-linux/pull/2725
To enable tests which depend on libgirepository's GIR and typelib,
we need to refactor the order we're currently building these items.
We can also move everything under girepository/ to cleanup the
top-level.
This allows the tests to be run with `meson test --setup thorough` and
it will run all the GTest tests with `-m thorough`.
Since this argument isn’t supported by the Python tests, it’s not passed
to them.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Introduce g_log_writer_syslog() that is suitable for use as a
GLogWriterFunc and sends the log message to the syslog daemon.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
So they are consistent with the way we’re building man pages in other
projects, and because some people are allergic to XML.
This changes the build-time dependencies from `xsltproc` to `rst2man`,
and also takes the opportunity to change the `-Dman` Meson option from a
boolean to a feature (so you should use `-Dman-pages={enabled,disabled}`
now, rather than `-Dman={true,false}`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Generating gir and typelib files has inter-dependencies that may depend
on other elements.
For example, glib requires gobject and gdump generated files require
gmodule, so we've a cyclic dependency because gmodule requires gobject,
that requires glib.
To prevent this, let's just generate the introspection files at once in
a different meson file so that we don't have to deal with this.
As per this we could even revert commit fa37ab6d0 since gio is now
compiled before the gir files.
Because the documentation is no longer built using gtk-doc.
Keep the old option around, but deprecated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The `#include <langinfo.h>` in `gdatetime.c` is currently predicated on
`HAVE_LANGINFO_TIME`, but it’s needed for all the `HAVE_LANGINFO_*`
features.
It seems the code implicitly assumes that `HAVE_LANGINFO_TIME` will be
true if any other `HAVE_LANGINFO_*` macros are true. While I haven’t
seen this assumption be broken in practice, it seems prudent to
explicitly encode that in the configure tests. It’s easy enough to do.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
The test needs to call `ftruncate64()` (not `ftruncate()`) to guarantee
it’s using the 64-bit version on Linux, but this doesn’t exist on other
platforms.
Test to see if it exists and, if not, skip the test.
Fixes commit cf5e371c67, and fixes CI
failures like https://gitlab.gnome.org/GNOME/glib/-/pipelines/602930.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
