The selling features are:
* Support for RESOLVE_BENEATH, RESOLVE_IN_ROOT and RESOLVE_NO_SYMLINKS
* Fallback from openat2 to open_tree to openat for compatibility
* Triggering of automounts
Recent versions of openSUSE default to using -Werror=return-type for
package builds, which results in all of these function checks
incorrectly detecting the function as not being available.
Co-authored-by: Peng Yi
Resolves: https://gitlab.gnome.org/GNOME/libglnx/-/issues/4
Signed-off-by: Simon McVittie <smcv@debian.org>
These will be new API in GLib 2.79.2.
The only code change in the implementation, other than the _glnx
wrappers, was to use `close()` instead of `g_close (fd, NULL)` in a
context where it must be async-signal safe.
The test-case needed some more adjustments to be backwards-compatible
with GLib from the distant past.
Signed-off-by: Simon McVittie <smcv@collabora.com>
libglnx is intentionally not portable to non-Unix platforms or to
compilers that do not implement gcc/clang extensions, so it's
counterproductive to warn about these extensions, even if libglnx is used
by a parent project that generally (for the parts that don't use
libglnx) wants to be portable to any ISO C compiler.
Suggested by Will Thompson on !36.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This includes a test (who tests the tests themselves?). Run
as `${build}/tests/testing --tap` with semi-modern GLib, or
`${build}/tests/testing --verbose` with GLib < 2.38, to check that the
output is as reasonable as possible given the limitations of the GLib
version in use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
A lot of recent convenience APIs can easily be backported, but they'll
clutter glnx-backports.h. In preparation, split these out.
Another reason to separate these is that when we start adding backports
of test utilities that need implementation code in the libglnx static
library, we'll want their implementations to be in a separate
translation unit, so that they don't get linked into production
executables, only into tests.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Warning level 2 is -Wall -Wextra, and warning level 3 adds -Wpedantic
(warnings about use of non-ISO extensions). libglnx is intentionally
using non-ISO features, so -Wpedantic is counterproductive.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we keep this module closer to warnings-clean, then it can be
submoduled into Meson projects that enable warnings by default without
having to override it to a lower warning-level.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This copylib isn't intended to be part of anyone's ABI. In Autotools,
this is typically implemented by doing some ad-hoc compiler checks and
adding -fvisibility=hidden to the global CFLAGS of any library that
pulls in libglnx, but in Meson it's a build system feature.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we don't do this, users of libglnx all have to add this dependency
themselves, otherwise they'll get errors like:
fatal error: gio/gfiledescriptorbased.h: No such file or directory
Signed-off-by: Simon McVittie <smcv@collabora.com>
To fill in some gaps, I've had to make some assumptions:
* trivial changes (such as checking for an additional function or
header file in libglnx.m4) are assumed to not be copyrightable
* Will Thompson and Matthew Leeds are assumed to be contributing on
behalf of Endless Mobile Inc.
* files with no explicit licensing information are assumed to be
under the license found in COPYING
Reference: https://reuse.software/
Signed-off-by: Simon McVittie <smcv@debian.org>
This avoids colliding with a config.h generated by a parent Meson
project.
In the Meson build system, we generate libglnx-config.h by doing our
own checks, so we want to avoid it colliding.
In the Autotools build system, we assume that the parent project will
generate its own config.h that contains the results of LIBGLNX_CONFIGURE,
and create a forwarding header libglnx-config.h in the $(top_builddir)
(so that it is next to config.h).
Note that after updating libglnx in an Autotools non-recursive-Make
project (libostree, flatpak, flatpak-builder) it will be necessary to
re-run autogen.sh.
Signed-off-by: Simon McVittie <smcv@collabora.com>
