This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
It's supposed to be possible to translate settings values using LC_TIME
rather than LC_MESSAGES to determine which translation to use, but
Sebastian Keller noticed that it's not working properly. I've
implemented his proposed solution, which is to actually temporarily
change LC_MESSAGES to match LC_TIME for just as long as necessary to
force gettext to use the desired message catalog.
Fixes#2575
Fix typo in gio/gappinfo (duplicated word)
Fix typo in gio/gtlsdatabase.c (duplicated word)
Fix typo in gio/gapplication.c (duplicated word, previous words rearranged to improve readability)
Fix typo in glib/tests/gvariant.c (duplicated word)
Fix typo in glib/win_iconv.c (duplicated word)
Fix typo in gio/gschema.dtd (meaning, missing letter)
Fix typo in gio/gdbusintrospection.c (duplicated word)
Fix typo in gio/gdbusintrospection.c (duplicated word).
As commit 44616ebafd ('gmain: More explicitly document
g_main_context_release() prereqs') correctly notes, you need to have the
context acquired before releasing it (just like a ref must match an
unref).
Commit 3926af723a ('gmain: Add precondition assertions to
g_main_context_release()') then goes one step further, and requires that
the calling thread is also the owner (the thread, that acquired the
context).
This is something which has been documented by g_main_context_release()
for years:
> Releases ownership of a context previously acquired **by this thread**
With acquire/release and g_main_context_is_owner() we track the thread
that acquired the context. That is mainly useful for asserting
correctness to not accessing the context from an unexpected thread.
Note that g_main_context_acquire() returns FALSE and does nothing when
the context is already acquired from another thread. Methods like
g_main_context_{prepare,query,dispatch}() require that the calling
thread is the owner (although, they don't assert for that, which they
maybe should).
With the assertion, it means you cannot pass an acquired context to
another thread for release. Obviously, if you pass on an acquired
context to another thread, the only next thing you can do is
g_main_context_release() (no acquire,prepare,query,dispatch). But it's
still useful to be able to release it, and to be able to keep it
acquired for a prolonged time.
libnm needs that, as it integrates a GMainContext into another
GMainContext. For that, it needs to acquire the inner context and keep
it acquired for as long as the context is integrated. Otherwise, when a
source gets attached to the inner context, the inner context is not
woken up (see g_source_attach_unlocked()). In commit e26a8a5981 ('Add
G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING'), a flag was introduced to solve
that same problem, without keeping the inner context acquired all the
time. Note that G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING is a flag of the
GMainContext, so it only works if the user who integrates the inner
context also controls how the context was created. For libnm, having
the inner context acquired at all times is no problem, because it's
understood that the user gives up agency on the inner context while it's
integrated. The only thing to consider is that the outer context might
be iterated on another thread. When calling prepare,query,dispatch on
the inner context, the code will notice it, release the inner context
and re-acquire it on the new thread ([1]). This works just fine, but it
requires that g_main_context_release() works from any thread.
So, in order to not break NetworkManager, let’s drop the ownership
assertion. However, NetworkManager is strictly breaking the API contract
here, and GLib reserves the right to re-add this assertion in future.
Still keep the assertion for the owner_count.
(Commit and commit message significantly updated by Philip Withnall; all
errors are his.)
[1] 9f01cff04f/src/libnm-glib-aux/nm-shared-utils.c (L4944)
Related: 3926af723a ('gmain: Add precondition assertions to g_main_context_release()')
Related: c67dd9d3fe ('gmain: Add a missing return on error path in g_main_context_release()')
Closes#3054
There’s no reason that anyone can think of that this should be
disallowed. It’s useful for language runtimes like GJS to be able to
find out the allocation size of dynamic GObjects.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #623
This reverts commit 252bbcd207.
After further discussion in !3511, we’ve decided that there are risks
associated with this change, and it’s not the best way of addressing the
original problem.
The original motivation for the change turned out to be that
`-mms-bitfields` was not handled by `windres`, which was receiving it
from `pkg-config --cflags glib-2.0` in some projects. However, if
`windres` is claiming to accept CFLAGS then it should accept (and
ignore) `-mms-bitfields`, since the `-m` family of options are defined
in `man gcc`, just like `-I`, `-D`, etc.
There is some question that there might still be third party projects
which are built with an old enough compiler that `-mms-bitfields` is not
the compiler default. For that reason, we should either still continue
to specify `-mms-bitfields` in the `.pc` file, or add a test to assert
that third party projects are always compiled with `-mms-bitfields` set.
But adding a new test for all third-party compilations is risky (if we
get it wrong, things will break; and it’s a test which may behave
differently on different platforms), so it seems safer to just keep
`-mms-bitfields` in `.pc` for now.
Once all compilers which we require specify `-mms-bitfields` by default,
we can finally drop this flag (without adding a test for third-party
compilations).
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511
The old name was not quite correct: the part of a URI which is just past
the scheme might be the hostname or the path. It isn’t necessarily just
a path.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Otherwise, crashing tests like assert-msg-test will still report to
pipe-based crash reporting frameworks like systemd-coredump, even though
the RLIMIT_CORE limit is zero.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I made the kqueue failure 100% reliable with `samu -j1` on FreeBSD,
and therefore confirmed this fixes that problem. Issue #2929 is
an identical failure on win32, so I assume this fixes that, too,
but I haven't confirmed.
Fixes: #2929
Following Emmanuele's instructions for use of introspection annotations:
https://www.bassi.io/articles/2023/02/20/bindable-api-2023/
I have audited all uses of the (closure) annotation in glib and
determined that only a handful are correct. This commit changes almost
all of our use of (closure) annotations to conform to Emmanuele's rules.
We don't know how big a pthread_key_t is, so we malloc() a big enough
chunk of memory for it and store a pointer into the GPrivate struct.
It turns out, on Linux, pthread_key_t is just an int, so we could much
easier just store it directly into the struct.
https://bugzilla.gnome.org/show_bug.cgi?id=737445Fixes: #931
g_private_get_impl() was returning a pointer to the pthread_key_t, but every
function using this was immediately dereferencing it. Change it so that we
dereference the value in the helper function and return it by value.
https://bugzilla.gnome.org/show_bug.cgi?id=737445
The test was passing fine when `bindir` was equal to `multiarch_bindir`,
but not when they differ.
For example, on a Debian system, `gio-querymodules` is installed to
`/usr/lib/x86_64-linux-gnu/glib-2.0/gio-querymodules` rather than
`/usr/bin/gio-querymodules` as it is on (say) Fedora.
This was causing the pkg-config tests to fail on Debian.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #3045
