tests/cxx-test.cpp is removed and splitted into gio/tests/cxx.cpp,
gmodule/tests/cxx.cpp and gobject/tests/cxx.cpp.

Helps issue #1434

g_module_open_full() is wrapper around g_module_open() function
which returns a GError in case of failure.

Closes #203

Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.

Fix a few of the links where they were hitting redirects or had moved.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2348

Specifically, for uclibc at the moment. Other implementations may need
locking, but I haven’t checked any aside from uclibc-ng and glibc.

POSIX.1-2001 specifies that `dlerror()` is not thread-safe, but the
glibc (and likely other libc) implementation is.

Issue #399 was originally reported about eglibc, but that project has
since died and been merged back into glibc. So that’s one less thing to
worry about.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #399

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

g_module_symbol() internally calls CreateToolhelp32Snapshot() which
in some circumstances returns ERROR_BAD_LENGTH and according to the docs
should lead to CreateToolhelp32Snapshot() being retried by the caller.

This retry logic was missing and for example led to g_module_symbol()
not succeeding if another thread happened to call the wrong function
at the wrong time.

This got noticed in the g-i build of gtk4 where g-i would call g_module_symbol()
on all gtk4 _get_type symbols and while inspecting the properties gtk4 would
spawn a thread calling SHGetSpecialFolderLocation() somewhere down the line.
During the call to SHGetSpecialFolderLocation() CreateToolhelp32Snapshot() would
return with ERROR_BAD_LENGTH for a short period of time and make g_module_symbol()
fail, which lead to "Invalid GType function" errors in g-i.

Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3213

This was mostly machine generated with the following command:
```
codespell \
    --builtin clear,rare,usage \
    --skip './po/*' --skip './.git/*' --skip './NEWS*' \
    --write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).

Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.

There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.

If I’ve missed anything, please file an issue!

Signed-off-by: Philip Withnall <withnall@endlessm.com>

By default, meson builds glib with -Werror=format=2, which
implies -Werror=format-nonliteral. With these flags, clang errors
out on e.g. the g_message_win32_error function, due to "format
string is not a string literal". This function takes a format
string, and passes the va_list of the arguments onwards to
g_strdup_vprintf, which is annotated with printf attributes.

When passing a string+va_list to another function, GCC doesn't warn
with -Wformat-nonliteral. Clang however does warn, unless the
functions themselves (g_message_win32_error and set_error) are decorated
with similar printf attributes (to force the same checks upon the
caller) - see
https://clang.llvm.org/docs/AttributeReference.html#format
for reference.

Adding these attributes revealed one existing mismatched format string
(fixed in the preceding commit).

Meson 0.54.0 added a new method meson.override_dependency() that must be
used to ensure dependency consistency. This patch ensures a project that
depends on glib will never link to a mix of system and subproject
libraries. It would happen in such cases:

The system has glib 2.40 installed, and a project does:
dependency('glib-2.0', version: '>=2.60',
  fallback: ['glib', 'glib_dep'])
dependency('gobject-2.0')

The first call will configure glib subproject because the system libglib
is too old, but the 2nd call will return system libgobject.

By overriding 'gobject-2.0' dependency while configuring glib subproject
during the first call, meson knows that on the 2nd call it must return
the subproject dependency instead of system dependency.

This also has the nice side effect that with Meson >0.54.0 an
application depending on glib can declare the fallback without knowing
the dependency variable name: dependency('glib-2.0', fallback: 'glib').

Since is_unref |= 1, the second argument, gboolean is_unref, has had
no effect.