Now that the reference documentation uses gi-docgen, it's more
troublesome to generate in less standard build scenarios like
cross-compiling.
In distributions like Debian, reference documentation is generally
packaged separately (in libglib2.0-doc in Debian's case), but man pages
are generally packaged alongside the executables themselves (in the
libglib2.0-bin and libglib2.0-dev-bin packages, in Debian's case). We
can exclude the reference documentation when cross-compiling, but ideally
we would like the man pages to still be built, so that a cross-compiled
libglib2.0-bin or libglib2.0-dev-bin package has the same content as a
native build.
Signed-off-by: Simon McVittie <smcv@debian.org>
Previously, the girs and typelibs generated from gobject-introspection
ommited the deprecated apis, however we want them annotated for
documentation purposes.
Skip the deprecated gthead api so they do not make it into the
typelibs which caused problems as not all the symbols exist.
See https://gitlab.gnome.org/GNOME/gjs/-/issues/595
Comparing reallocated pointers is UB, but this happens to work for now
on most compilers. However, for CHERI systems if g_bsearch_array_insert()
reallocs in-place then the new `hlbsa` pointer may have larger bounds
than `o` and using the old pointer with the smaller bounds can result
in a bounds error. I don't think this code is performance critical, so
removing the optimization and inserting unconditionally should be fine.
Currently, this realloc() UB rarely causes issues, but newer versions of
GCC with _FORTIFY_SOURCE=3 might also be able to observe the valid
memory range (assuming sufficient inlining).
See https://developers.redhat.com/articles/2022/09/17/gccs-new-fortification-level
Introduce g_log_writer_syslog() that is suitable for use as a
GLogWriterFunc and sends the log message to the syslog daemon.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Not sure what it was doing there — these arguments get written to as
part of the invocation. The in-args should be `const` qualified, but not
the out-args.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The whole point of a `GICallableInfo` struct is to contain information
about how a function is callable, and that includes information about
whether it’s a method and whether it throws a `GError`. The caller
shouldn’t need to specify those things separately.
So drop those arguments.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s more descriptive and less offensive.
This is not an API break as it’s not a public API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It was deprecated since before libgirepository was moved into this
repository. Take the opportunity now to remove it entirely, as it’s a
bit confusing to have it in the public API.
This should not affect the binary typelib format, as it still has its
`BLOB_TYPE_INVALID_0` member, and that will remain in place until the
binary format next breaks compatibility (no plans to do that).
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
And rename it to `gi_repository_get_shared_libraries()`. Previously it
returned a comma-separated string, which wasn’t particularly typesafe or
machine-friendly. Now it returns the same data as an array.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Having it be nullable means the type system forces the caller to check
the result for nullability every time, even though it’s straightforward
for the caller to check the index argument in advance and guarantee a
non-`NULL` result.
Change `gi_repository_get_info()` to never return `NULL` to tidy this
up. This also brings it inline with other `gi_*_get_info()` functions,
which are not nullable.
This is an API break in libgirepository, but since it’s not been in a
stable release yet, that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
The generated docs are discarded by `meson dist` after building the dist
tarball, so we need to compile them again. And they get generated in the
`_build` directory, not the source directory.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In general, we must not call out to external, unknown code while holding
a lock. That is prone to dead lock.
g_object_ref() can emit a toggle notification. In g_weak_ref_set(), we
must not do that while holding the lock.
The optional flags should be used for bit locks. That means,
we must only use atomic operations when updating the flags.
Having a variant of _X methods that update the flags without
locks (_X), means that we must take care not to take bit locks
during construction.
That is hard to get right. There is so much happening during object
construction, that it's unclear when it's really safe to access the
flags without atomic. Don't do this.
Add a GObjectPrivate struct and let GObject have private data.
On architectures where we have an alignment gap in GObject struct (64
bit), we use the gap for "optional_flags". Use the private data for
those optional flags, on architectures where we don't have them.
For now, private data is only added for those optional flags (and not on
architectures, where the flags fit inside GObject). In the future, we
may add additional fields there, and add the private struct always.
The main purpose will be to replace all the global locks with per-object
locks, and make "optional_flags" also available on 32bit.
_Thread_local is also C11, so possibly other compilers would also support
it.
However, since not *all* compilers support it, it can anyway only be
used as optimization and conditional asserts. As such, the current
detection based on __GNUC__ to only support gcc (and clang) is good
enough.
GWeakRef calls g_object_ref() while holding a read lock.
g_object_ref() can emit a toggle notification.
If you then inside the toggle notification setup a GWeakRef
(to the same or another object), the code will try to get
a write lock. Deadlock will happen.
Add a test to "show" that (the breaking part is commented out).
Will be fixed next.
This was done manually, but the changes are very repetitive. There are
some minor rewordings/formatting tweaks included. The bulk of the
changes are to the linking syntax.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
For the same reasons as in commit 71061fdcb3, but in this
case we can’t downgrade the version of Meson on the CI runner, so just
tell it to shut up instead.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s still going to be used on the `glib-2-78` branch because the
dependencies there are frozen, but since it’s EOL it can’t have
additional dependencies (like the Python `packaging` package) installed
for `main`, so let’s drop it. We have the FreeBSD 13 runner on `main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740#note_1957840
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This reverts commit 35ec6b6387.
The FreeBSD 13 CI runner now has the Python `packaging` package
installed, so should work again.
The FreeBSD 12 runner is EOL so can’t have that package installed, so
will be dropped from GLib `main` in the next commit.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3740#note_1957840
In g_object_unref(), we call _object_unref_clear_weak_locations() before
and after dispose() already. At those places it is necessary to do.
Calling it a third time during g_object_real_dispose() seems not useful,
has unnecessary overhead and actually undesirable.
In particular, because g_object_real_dispose() is the implementation for
the virtual function GObject.dispose(). For subclasses that override dispose(),
it's not well defined at which point they should chain up the parent
implementation (for dispose(), I'd argue that usually they chain up at
the end of their own code). If they chain up at the end, this has no
effect.
This only really matters if you try to register GWeakRef during dipose
and/or resurrect the object.
static void dispose(GObject *object)
{
g_weak_ref_set(&global_weak_ref, object);
global_ref = g_object_ref(object);
G_OBJECT_CLASS (parent_class)->dispose (object);
}
the object was resurrected, but g_object_real_dispose() would clear the
weak ref. That is not desirable, nor does it make sense.
Instead, the virtual function dispose() is called from two places, from
g_object_unref() and g_object_run_dispose(). In both cases, it is
ensured that weak locations are cleared *after* dispatching the virtual
function. Don't do it somewhere in the middle from
g_object_real_dispose().
A few applications such as gnome-music load the GIRepository typelib
and use it to adjust their search paths.
GLib 2.79.x now provides libgirepository-2.0.so.0 (GIRepository-3.0),
but each OS distribution is likely to have a transitional period during
which GLib's libgirepository-2.0.so.0 has become available, but bindings
like PyGI and gjs are still linked to gobject-introspection's
libgirepository-1.0.so.1 (GIRepository-2.0).
During this transitional period, interpreted languages that load the
GIRepository namespace could get the "wrong" version, which will result
in adjusting a search path that will not actually affect the language
binding's typelib lookup, and could also lead to symbol and type-system
conflicts.
We can avoid this collision by making GLib's GIRepository library refuse
to load versions of the GIRepository typelib that are not 3.0, and
similarly making gobject-introspection's GIRepository library refuse to
load typelib versions that are not 2.0. A relatively neat way to achieve
that is to make each version behave as if the other one doesn't exist.
Signed-off-by: Simon McVittie <smcv@debian.org>
