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.
Resolve "g_date_time_format() does not return UTF-8 if LC_TIME is not UTF8 but other locale settings are UTF-8"
Closes#2055
See merge request GNOME/glib!1777
Make msvc_recommended_pragmas.h work better with clang-cl so that we can
use that to eliminate some warnings that are emitted as it also consumes
Microsoft compiler and SDK headers.
Also, for GLib builds, force-include msvc_recommended_pragmas.h for
clang-cl builds as well, as it becomes usable and useful there.
Fixes issue #2357.
Functions (_g_get_time_charset and _g_get_ctype_charset) to get LC_TIME and LC_CTYPE charset
by using nl_langinfo with _NL_TIME_CODESET and CODESET).
Another functions (_g_locale_time_to_utf8 and _g_locale_ctype_to_utf8) which uses thel and format
the input string accordingly.
Add new test cases with mixing UTF8 and non UTF8 LC_TIME along with UTF8
and non UTF8 LC_MESSAGES.
Closed#2055
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
This will require distributions to ensure they pass
`--localstatedir=/var` correctly to Meson, but they should be doing that
already.
See https://mesonbuild.com/Builtin-options.html#directories for details
about how Meson treats `localstatedir` differently from most other `dir`
variables.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Meson incorrectly detects strcasecmp, strncasecmp on clang-cl if 'prefix:'
is not specified for cc.has_function().
See https://github.com/mesonbuild/meson/issues/5628
Fixes https://gitlab.gnome.org/GNOME/glib/-/issues/2337
Before this change:
msvc was using _stricmp()
gcc on mingw was using strcasecmp()
gcc on linux was using strcasecmp()
clang-cl was trying to use strcasecmp()
After this change:
msvc is using _stricmp()
gcc on mingw is using strcasecmp()
gcc on linux is using strcasecmp()
clang-cl is using _stricmp()
Tests are still failing to build with clang-cl, but that's a separate issue.
With bash completion version lesser than 2.10, only prefix is defined
while for greater version it is datadir.
Closes#1054
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
The function declaration we use changed a bit since then.
In particular, some arguments became const. See following commit.
libselinux-2.2 was released on 20131030, and is widely available in
all major stable distributions.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
It’s landed in kernel 5.9: http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html
Note, this is untested because I currently don’t have kernel 5.9. We can
fix anything up if it breaks once the new syscall is wrapped in glibc.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This currently just implements the same functionality as the existing
`stat()`/`fstat()`/`fstatat()`/`lstat()` calls, although where a reduced
field set is requested it may return faster.
Helps: #1970
cc.has_function() provide false positive for Android-20 and earlier; the fix is in Meson 0.54.2. People attempting to cross-compile previously wouldn’t have been able to get it to work without manual intervention, so the dependency bump for this platform is not an additional obstacle for them.
In cases where performance are critical it can be useful to disable
checks and asserts. GStreamer has those options too, using the same name
and setting them yielding means we can set those options on the main
project (e.g. gst-build) and glib will inherit the same value when built
as subproject.
`get_option('buildtype')` will return `'custom'` for most combinations
of `-Doptimization` and `-Ddebug`, but those two will always be set
correctly if only `-Dbuildtype` is set. So we should look at those
options directly.
For the two-way mapping between `buildtype` and `optimization`
+ `debug`, see this table:
https://mesonbuild.com/Builtin-options.html#build-type-options
The test code can be built on Windows using Cygwin or MSYS2.
Even though it's test code, it might bring assertion dialog box
for native Windows while meson configure.
There were a couple of custom paths which could end up being relative,
rather than absolute, due to not properly prefixing them with
`get_option('prefix')`.
The use of `join_paths()` here correctly drops all path components
before the final absolute path in the list of arguments. So if someone
configures GLib with an absolute path for `gio_module_dir`, that will be
used unprefixed; but if someone configures with a relative path, it will
be prefixed by `get_option('prefix)`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1919
This is required to be able to build the doc. The debian docker is still
pinned to 0.49.2 which ensure we can build with both versions of meson.
Meson 0.52.0 warns about adding -Wall flag manually, we can remove that
because warning_level=1 (the default) option already implies it.
By default (on POSIX) we would be inheriting thread priorities from the
thread that pushed a new task on non-exclusive thread pools and causes a
new thread to be created. This can cause any non-exclusive thread pool
to accidentally contain threads of different priorities, or e.g. threads
with real-time priority.
To prevent this, custom handling for setting the scheduler settings for
Linux and Windows is added and as a fallback for other platforms a new
thread is added that is responsible for spawning threads for
non-exclusive thread pools.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1834
It's not supported on macOS' clang compiler and will fail the visibility
check and thus make the G_GNUC_INTERNAL attribute do nothing.
Compiler stderr:
/var/folders/nt/j2v2x4wd5cl33fq27mm31mwc0000gn/T/tmpxxf2zzi_/testfile.c:13:19: error: target does not support 'protected' visibility; using 'default' [-Werror,-Wunsupported-visibility]
__attribute__ ((visibility ("protected")))
^
1 error generated.
Checking if "GNU C visibility attributes test" compiles: NO
When choosing the type to base `size_t` on, check the compatibility of
passing pointers, as well as the width of the type, to avoid compiler
warnings in future.
For now, the code to do the checks is fairly ugly due to limitations in
Meson. In particular, the new checks are limited to gcc and clang (other
compilers will behave as before), and they are all duplicated. See the
comments in the code for links to Meson improvement requests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1777
If we're cross-compiling, the installed-tests are useful even if we
can't run them on the build machine: we can copy them to the host
machine (possibly via a distro package like Debian's libglib2.0-tests)
and run them there.
While I'm changing the build-tests condition anyway, deduplicate it.
Based on a patch by Helmut Grohne.
Bug-Debian: https://bugs.debian.org/941509
Signed-off-by: Simon McVittie <smcv@collabora.com>
We already depend on Meson 0.49.2, which depends on Python 3.5, so we’ve
actually implicitly had this requirement for a while. Might as well make
it explicit.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Instead of letting each directory to find its way to link with libdl,
it is easier to put the check in the top level, so its result can be
used by all directories.
It is a follow-up of https://gitlab.gnome.org/GNOME/glib/merge_requests/810.
Also set the Windows version to be 10 or newer when targeting UWP, since
the Windows 8 SDK does not have many of the APIs we need, such as
_beginthreadex.
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.
