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.
