We cannot bump to the latest stable version of Meson, even if it would
make our life easier. We can, though, use the version of Meson shipped
by the next, soon to be released Debian stable.
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
The plugin modules in these tests get statically linked with a separate
copy of GLib so they end up calling vfuncs in their own copy of GLib.
Fixes#1648
GLib checks for __sync_bool_compare_and_swap, and requires
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to be defined if the function is available,
except with special cases like Linux armv5.
Extend the existing workaround to unbreak on old gcc versions that implement
__sync_bool_compare_and_swap but don't provide __GCC_HAVE_* macros.
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
We are still seeing occasional CI failures due to timeouts when heavily
loaded. It’s best to wait a little longer than to throw all the results
out when they’re almost done.
For example, see https://gitlab.gnome.org/tristan957/glib/-/jobs/331330.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The code in gunicollate uses __STDC_ISO_10646__ to check that wchar.h is avilable,
that it includes the wide character related functions and that sizeof(wchar_t) == 4.
cygwin defines __STDC_ISO_10646__ and has sizeof(wchar_t) == 2 and the C standard text isn't
that clear on whether wchar_t should always be 4 bytes in this case, so we better not use if for
assuming the size here.
Instead of relying on __STDC_ISO_10646__ add HAVE_WCHAR_H and SIZEOF_WCHAR_T macros.
With HAVE_WCHAR_H defined we assume wchar_t exists and wchar.h exists. With SIZEOF_WCHAR_T we
guard the parts where the size of wchar_t is assumed to be 4 (currently all of them).
Note that this doesn't make the collate tests pass under cygwin, they fail before and after this patch for me.
See !755 for related discussions.
The correct spelling is "_NL_ABALTMON_n" rather than "_NL_ALTMON_n".
The typo made Meson build think that _NL_ABALTMON_n constants are
not supported which was totally wrong. This made g_date_time_format()
output incorrect abbreviated month names in some languages.
The old configure.ac script was correct here.
Bug introduced in commit be4f96b650.
Closes: #1759
Currently, there is no way to prevent tests from building using meson.
When cross-compiling, building the tests isn't necessary.
Instead, only build the tests on the following conditions:
1) If not cross-compiling.
2) If cross-compiling, and there is an exe wrapper.
Instead of requiring the user to specify which option to use, which
they will not really know, nor should they need to know.
Search for each type of iconv (in the C library, as a separate
native library, as the GNU implementation) by default.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1557
Add a missing ifdef from gfileutils.c that is needed for O_BINARY.
The other option was to remove O_BINARY, but i left it there for
the sake of completeness, as this is what g_file_get_contents() uses.
Instead of hardcoding /proc/self/cmdline use for __linux__ only,
do a configure-time test for it.
Specifically, this enables /proc/self/cmdline use on Cygwin.
The configure-time test is very primitive (just tests that the
file exists and that it's possible to read more than one byte from it),
relying on the testsuite for more extensive checks.
The test in the testsuite is modified to always run, even on platforms
where it isn't supposed to pass. If it fails there, the testing framework
skips it. If the test unexpectedly passes, that is reported too.
Check for RTLD_NEXT being present, and disable the gsocketclient-slow
test if it's absent, since the shlib dependency of that test requires
RTLD_NEXT to function.
This allows the testsuite to be built on Cygwin, which behaves
exactly like UNIX, but doesn't have RTLD_NEXT.
This macro was lost during meson migration. Set it again.
Also explain that Cygwin maintainers applied patches[0] to glib that
simply marked all G_PLATFORM_WIN32-protected code as !defined(G_WITH_CYGWIN),
i.e. they did not want that code to compile.
Instead of altering ifdef guards all over the place, we'll just
not define G_PLATFORM_WIN32 for Cygwin anymore.
[0]: 3a873fdd1b/2.36.3-not-win32.patch
In cross-compilation environments the runtime check isn't possible so it is up
to the builder to seed the cross file, but we can definitely state that strlcpy
doesn't exist with a build test.
Those lists were getting very long. We can’t quite entirely automate the
list generation since Meson doesn’t have a range() function, but we can
at least combine three of them into one.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
A lot of code cast function pointer to incorrect types. There is no
other way but silencing the warning. Follows an example of such cast:
glib/glist.c: In function ‘g_list_free_full’:
glib/glist.c:223:25: error: cast between incompatible function types from ‘GDestroyNotify’ {aka ‘void (*)(void *)’} to ‘void (*)(void *, void *)’ [-Werror=cast-function-type]
g_list_foreach (list, (GFunc) free_func, NULL);
^
It is not always needed to generate and install gmo files, for example
when building for Android or Windows that often doesn't have libintl to
use them anyway.
At least all GStreamer modules have this same option.
This is enough for most Debian buildds, including embedded devices
like mips and powerpcspe. It is not enough for hppa (PA-RISC), but that
architecture is so uniquely slow that it might make more sense to
special-case it downstream.
Signed-off-by: Simon McVittie <smcv@collabora.com>
armv5 Linux systems implement __sync_bool_compare_and_swap() and
friends by calling a function provided by the kernel. This is not
technically an atomic intrinsic, so gcc doesn't define
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 in this case, but it's good
enough for us. Extend the current Android special case to cover
GNU/Linux too.
The possibilities are:
* __sync_foo detected and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 predefined:
calls to __atomic_foo or __sync_foo primitives are inlined into user
code by gatomic.h
* __sync_foo detected but __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 not
predefined: user code has an extern reference to g_atomic_foo(),
which calls __atomic_foo or __sync_foo because we defined
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 when compiling GLib itself
* Windows: user code has an extern reference to g_atomic_foo(),
which calls InterlockedFoo()
* !defined(G_ATOMIC_LOCK_FREE): user code has an extern reference to
g_atomic_foo(), which emulates atomic operations with a mutex
Signed-off-by: Simon McVittie <smcv@collabora.com>
Closes: #1576
FreeBSD 12 adds a new header, sys/auxv.h, to declare a function, elf_aux_info,
for public use, which was considered an internal function in previous releases.
This new function provides similar functionality with glibc getauxval, which is
also declared in the same header, but their interfaces are not compatible. Since
the only usage of sys/auxv.h is in g_check_setuid and FreeBSD already has
issetugid to provide the required functionality, we fixes the compilation error
by adding a check for getauxval function to prevent g_check_setuid from calling
getauxval when sys/auxv.h is found but getauxval is not available.
https://reviews.freebsd.org/D12743https://reviews.freebsd.org/rS324815
Partial revert of commit a7a6449f4d.
Checking for the availability of m4 for installing m4 macro files
creates an implicit dependency on m4 even if GLib does not need it; this
prevents building GLib and then installing Autotools in order to build a
project that depends on GLib.
Closes#1520
We already set -Wformat=2, which implies -Wformat-security, so there’s
no need to test for and set -Wformat-security separately.
The test for -Wformat-security never worked anyway, since gcc complains
if it’s specified without also setting -Wformat to some value. The
complaint causes configure.ac/meson.build to assume the option doesn’t
work.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/656
I can’t see this being used anywhere in GLib, or in my /usr/include
directory. I’m also not sure how configure.ac ends up defining it — it’s
certainly as a side-effect of something, and not deliberate.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1313
Previously we weren’t checking for it in meson.build (but were checking
for it in configure.ac, courtesy of glib-gettext.m4). Roughly emulate
the checks from glib-gettext.m4, checking for bind_textdomain_codeset()
in whichever libintl implementation we found ngettext() in.
meson.build still doesn’t implement the full set and order of checks in
glib-gettext.m4; there’s still a FIXME about that in meson.build.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1313
Previously it was hard-coded to true, rather than being based on the
calculations actually made by meson.build.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1313
This is equivalent to the AC_FUNC_PRINTF_UNIX98 macro which we use in
configure.ac. There may still be some obscure Unix platforms which don’t
natively support positional parameters, 20 years on.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1313
This is what Autotools does, and it's what all consumers of the
GModule API expect. Without this change, people on macOS upgrading to
a GLib built with Meson will find that their plugins no longer load.
Projects that use Meson and the `g_module_build_path()` API such as
glib-networking should pass `name_suffix:` to `shared_module()` to
ensure that plugins continue to be called libfoo.so on macOS.
New GModule API will eventually be added to address this.
See also:
https://gitlab.gnome.org/GNOME/glib/issues/1413a3d81719fe/meson.build (L108)
The goal of this commit is to reduce differences between the autotools and meson build.
With autotools AC_FUNC_ALLOCA was used which defines HAVE_ALLOCA_H, HAVE_ALLOCA,
C_ALLOCA. meson tried to replicate that with has_function() but alloca can be a macro
and and is named _alloca under Windows. Since we require a working alloca anyway
and only need to know if the header exists replace AC_FUNC_ALLOCA with a simple
AC_CHECK_HEADERS.
There is still one user of HAVE_ALLOCA in the embedded gnulib, but since alloca is
always provided through galloca.h just force define HAVE_ALLOCA there and add a comment.
The docs were mentioning alloca as an example for cross compiling. Since that variable no
longer exists now replace it with another one.
Check for compile warnings when assigning an int64_t* to a long*,
make gint64 a long long if they occur and assigning an int64_t* to
a long long* doesn't.
Modified by Philip Withnall <withnall@endlessm.com> to support Meson as
well as autotools.
https://gitlab.gnome.org/GNOME/glib/issues/972
The autotools build set it by default and we use off_t in various places,
even on Windows. Also set it with the meson build to avoid any regressions.
Ideally we shouldn't use off_t and use 64bit capable API on Windows instead, so
we get large file support with MSVC as well.
See https://mail.gnome.org/archives/desktop-devel-list/2018-July/msg00004.html
for a discussion on if/when we can start relying on Python 3 only.
Use Python 3.4 as a new requirement because that's the version used in
SLES 12 and Debian 8 and there is no good reason to require something newer
right now.
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
When compiling third-party projects with -Wbad-function-cast, the inline
g_atomic_pointer_get() implementation which uses C11 __atomic_load*()
calls on GCC was causing compilation errors like:
error: cast from function call of type ‘long unsigned int’ to non-matching type ‘void *’
While we don’t want to compile all of GLib with -Wbad-function-cast, we
should support its headers being included in projects which do enable
that warning.
It doesn’t seem to be possible to cast away the warning (e.g. by casting
the function’s result through (void)), so we have to assign to an
intermediate integer of the right size first.
The same has to be done for the bool return value from
__sync_bool_compare_and_swap(). In that case, casting from bool to
gboolean raises a -Wbad-function-cast warning, since gboolean is
secretly int.
The atomic tests have been modified to enable -Wbad-function-cast to
catch regressions of this in future. The GLib build has conversely been
modified to set -Wno-bad-function-cast, just in case people have it set
in their environment CFLAGS.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1041
This requires meson >= 0.47.0 otherwise building the doc fails:
https://github.com/mesonbuild/meson/issues/3379
While at it, no need to to pass --prefix --libdir to meson, other CIs
don't have them.
When the amount of free memory on the system is somewhat low, gnome-shell
will sometimes fail to launch apps, reporting the error:
fork(): Cannot allocate memory
fork() is failing here because while cloning the process virtual address
space, Linux worries that the thread being forked may end up COWing the
entire address space of the parent process (gnome-shell, which is
memory-hungry), and there is not enough free memory to permit that to
happen.
In this case we are simply calling fork() in order to quickly call exec(),
which will throw away the entirity of the duplicated VM, so we should
look for ways to avoid the overcommit check.
The well known solution to this is to use clone(CLONE_VM) or vfork(), which
completely avoids creating a new memory address space for the child.
However, that comes with a bunch of caveats and complications:
https://gist.github.com/nicowilliams/a8a07b0fc75df05f684c23c18d7db234https://ewontfix.com/7/
In 2016, glibc's posix_spawn() was rewritten to use this approach
while also resolving the concerns.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9ff72da471a509a8c19791efe469f47fa6977410
I experimented with a similar approach in glib, but it was not practical
because glibc has several items of important internal knowledge (such as
knowing which signals should be given special treatment because they are
NPTL implementation details) that are not cleanly exposed elsewhere.
Instead, this patch adapts the gspawn code to use posix_spawn() where
possible, which will reap the benefits of that implementation.
The posix_spawn API is more limited than the gspawn API though,
partly due to natural limitations of using CLONE_VM, so the posix_spawn
path is added as a separate codepath which is only executed when the
conditions are right. Callers such as gnome-shell will have to be modified
to meet these conditions, such as not having a child_setup function.
In addition to allowing for the gnome-shell "Cannot allocate memory"
failure to be avoided, this should result in a general speedup in this
area, because fork()'s behaviour of cloning the entire VM space
has a cost which is now avoided. posix_spawn() has also recently
been optimized on OpenSolaris as the most performant way to spawn
a child process.
