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.
We don’t strictly require this, but given that our CI runs it, we
essentially never test with 0.46.0, so it might as well be broken.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
We have not updated nor used this script for a long time, and nowadays
Meson makes it much easier to build on Windows for either Visual Studio
or MinGW, even straight from a GIT checkout, so it's about time that we
drop the glib-zip script from the source tree.
Autoconf macro AC_HEADER_MAJOR doesn't define a macro in config.h when
major is defined in sys/types.h. This was not a problem because major
is assumed to be always available. However, commit aefffa3fbc
changes this assumption in order to fix build on systems without major,
which causes code using major to be disabled on systems putting major
in sys/types.h.
This commit defines a new macro MAJOR_IN_TYPES for both autotools and
meson builds to make major useful on these systems again.
cc.has_header checks whether a header exists without knowing whether it
can be used. This is a problem on FreeBSD because its malloc.h is a
header with an '#error' line which always throw compilation error. To
avoid false positive in the check result, we use cc.compiles to do a
full compilation test instead of cc.has_header which only does check
with preprocessor.
We have no way to test Solaris builds atm, and it is not even clear how
to detect Solaris systems with meson. It will probably need to be
revisited when we get a proper CI in place.
See commit 4c2928a544 for why checking AT_SECURE is preferable compared
to UID checks as currently done in the fallback case.
getauxval() was added with glibc 2.16
While glibc <2.19 didn't provide a way to differentiate a 0 return value from an error,
passing AT_SECURE should always succeed according to
https://sourceware.org/ml/libc-alpha/2014-07/msg00407.html
I've added an errno check anyway, to be on the safe side.
Try and ensure that people don’t push code with misleading indentation
in future. This should give fairly few false positives.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
gcc defaults to utf-8 for both (see -fexec-charset and -finput-charset in the
gcc man page) so we should use it with msvc as well.
msvc by default uses the locale encoding unless there is a BOM, see
https://msdn.microsoft.com/en-us/library/mt708821.aspx
Our minimum requirement is already greater than that, so we don't need
to add checks there. We can always add -Wl,-framework,CoreFoundation
flag.
Fixes#1380.
- Compiler checks were failing because it were using C compiler to build
objc code.
- xdgmime is needed on osx too.
- -DGIO_COMPILATION must be passed to objc compiler too.
- gapplication doesn't build on osx, it is excluded in autotools too.
We have to be careful when we use add_project_link_arguments(): All
targets are built using link arguments for the C language, except for
libgio on osx which use the objc language, because it contains some ".m"
source files. See https://github.com/mesonbuild/meson/issues/3585.
https://bugzilla.gnome.org/show_bug.cgi?id=796214
Some compilers, particularly Android on armv5 and old versions of Clang
provide atomic ops, but don't define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
so we need to define it ourselves.
This matches what configure does, with the exception that now it's only
done for Android since clang defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
now.
https://bugzilla.gnome.org/show_bug.cgi?id=796325
The latest patches have fixed the atomic check, which
uses __sync_bool_compare_and_swap , and thus fails on
MSVC.
As a result, in gatomic.c, we ended up trying to include
pthread.h, which failed.
This mimics the old behaviour a bit more closely, where
G_ATOMIC_LOCK_FREE was always defined in the win32
glibconfig.h
https://bugzilla.gnome.org/show_bug.cgi?id=796220
The 'no-builtin' checks were just plain wrong. For accurate detection of
functions, use has_function with a header in the prefix. This fixes
posix_memalign detection on Android and on MinGW32, MSYS-MinGW-w64, and
old versions of MSYS2-MinGW-w64.
Using the header in the `prefix:` is generally a good idea because of
how macOS does targetting of specific macOS releases at compile time.
This also allows cross-files to override the result by setting
`has_function_stpcpy = false`, etc in [extra properties]
https://bugzilla.gnome.org/show_bug.cgi?id=795876
The comment stated that the test isn't good enough, but it correctly
detects a C99 printf when I build with -D__USE_MINGW_ANSI_STDIO=1
and an incompatible printf without it.
Using mingw-w64 from current MSYS2.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
This could have caused spurious test failures when running with -Werror,
due to the missing return statement in int main().
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
Commit 3e96523e6b did not entirely fix the test, as the compiled test
code did not have a main() function, so failed to link with:
/usr/lib/gcc/x86_64-redhat-linux/7/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
This caused an invalid mixtures of builtin and non-builtin atomics/locks
to be used, which caused deadlocks in a number of tests.
Fix the atomic ops test in meson.build, and the unit tests all start
working again.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=796164
This allows building with posix threads on Windows. It is generally
better to use win32 threads implementation on Windows, but this option
can be used in case it causes issues, or for performance comparison for
example.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
win32_cflags gets used globally as cflags and exposed in the .pc file.
win32_ldflags gets passed to glib-2.0 and exposed in the .pc file.
This should match what the autotools build is currently doing with
GLIB_EXTRA_CFLAGS and G_LIBS_EXTRA.
https://bugzilla.gnome.org/show_bug.cgi?id=784995
-z nodelete breaks the libresourceplugin module usage in the resources.c
test, which expects to be able to unload it.
Make the Meson build match what the autotools build does: only pass
glib_link_flags to the headline libraries (glib-2.0, gio-2.0,
gobject-2.0, gthread-2.0, gmodule-2.0) and omit it from all other build
targets.
https://bugzilla.gnome.org/show_bug.cgi?id=788771
On Windows we use gnulib and elsewhere we use glibc or similar.
Also change G_GNUC_PRINTF to use gnu_printf instead of __format__ if
possible because __format__ evaluates to ms_printf under MinGW,
but we use gnulib there and not the system printf.
gnu_printf is only available with GCC>=4.4 and not with clang.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
In https://bugzilla.gnome.org/show_bug.cgi?id=794555 the tests for
posix_memalign and stpcpy were extended to catch the case where
the compiler provides an incomplete builtin.
Under MSYS2 the example code still compiles and links while the real usage
of stpcpy fails to build. To prevent the MSYS2 gcc from using the builtin
versions pass -fno-builtin.
https://bugzilla.gnome.org/show_bug.cgi?id=793729
The winsock2-using test does work perfectly, however this is a new
thing that didn't exist in autotools-based builds of glib in the past.
Autotools builds used the generic case where values were just defined
to some agreed-upon numbers, and this is what all autotools-glib
binaries and binaries built against autotools-glib (since these
values go into public glibconfig.h header) use. At least one value,
G_POLLIN, is different, thus breaking ABI if some binaries are
built with autotools and the others are built with meson.
Force meson buildscript to use the same G_POLL* constant values
for Windows builds that autotools builds use.
https://bugzilla.gnome.org/show_bug.cgi?id=794687
When cross compiling and not exe wrapper has been defined cc.run() raise
an exception. Avoid this by taking the value from [properties] in the
cross file and provide sensible default if the variable is not defined.
https://bugzilla.gnome.org/show_bug.cgi?id=794898
Add a test for monitoring an existing local file, with the
WATCH_HARD_LINKS flag specified. This would previously cause a crash;
now it doesn’t.
This test contains a FIXME where I suspect we should be getting some
additional file change notifications from changes made through the hard
link; this requires further follow up and probably further fixes to our
inotify backend.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=755721
Accurate G_HAVE_GNUC_VISIBILITY is needed to correctly
define G_GNUC_INTERNAL later on. Autotools did that,
meson currently doesn't and opts to just set
G_HAVE_GNUC_VISIBILITY to 1 for all compilers except MSVC.
This leads to MinGW GCC having G_HAVE_GNUC_VISIBILITY=1,
which results in G_GNUC_INTERNAL being defined to
__attribute__((visibility("hidden"))), which is not supported.
Because cc.compiles() does not support override_options or
anything like that, we just feed it '-Werror' as-is, since
MSVC is known as not supporting visibility attributes anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=794636
GCC has built-ins for these functions, which might give a compile-only
test an impression that the functions are actually present in the C runtime.
Use a linked test to be sure.
Specifically, both functions are missing on Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=794555
Supports %OB (alternative, standalone, nominative) month name along
with the old %B (primary, in a complete date format context, genitive)
month name. Similarly %Ob and %Oh for abbreviated month names.
Depending on the underlying operating system uses nl_langinfo()
or provides our custom implementation.
(Tweaked by Philip Withnall <withnall@endlessm.com> to add test case
comment and bug reference.)
https://bugzilla.gnome.org/show_bug.cgi?id=749206
