If we use the system libraries we can't really debug it, so ensure we're
using the currently built libraries for it too.
We're doing it globally to ensure that we're testing the result that
this version of the libraries are building
In some test cases (but not only) GLib needs to preload libraries when
launching executables, however this doesn't work well with ASAN because
libasan needs to be the first library to be loaded in such case.
We've been ignoring the error so far, using verify_asan_link_order=false
ASAN option, but this is not the correct way because it implies that
we don't check any pre-loaded library, as we instead should.
So in the platforms we know, get the proper sanitizer libraries paths
and pre-load them when required.
We don't do it for installed tests since the full paths may change in
the target system, so ignoring the error is safer.
This meson code has been used for various years now in fprintd project
to run tests in CI in both fedora and debian-based systems with no
issues, so I consider it reliable.
In case no preload variables are found the default ignore mode is used
If preloading a library is required asan doesn't work properly because
it requires to be the first loaded library to test everything, however
the behavior can be worked around using an ASAN_OPTIONS variable, so do
this to prevent the tests to fail completely
But instead of having to do it at test level, manage this at wider scope
The deprecated construct '@0@'.format(h) (where h is a file object)
expanded to the filename relative to the project root, which in this
particular case happens to be what we wanted:
`--c-include=gio/gunixmounts.h` resulted in a recommendation to
`#include <gio/gunixmounts.h>` and so on. Replacing it with
h.full_path() resulted in GIR XML and documentation that recommended
constructs like `#include </home/me/src/glib/gio/gunixmounts.h>`,
which is not what was intended (and caused new differences between
different architectures' Gio-2.0.gir on multiarch systems, which is
how I discovered this).
Hard-coding `gio/` and appending the basename of the header seems like
the simplest non-deprecated spelling that will do what we wanted.
Fixes: 51e3e7d9 "build: Bump Meson dependency to 1.4.0"
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3564
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously `gi_object_info_find_signal()` used `gi_object_info_get_signal()`
to retrieve the *i*th signal and compare its name to the desired name.
However, `gi_object_info_get_signal()` returns an allocated object.
If the names were not matching, the allocated object was simply dropped,
and this resulted in a lot of unnecessary allocations compared to the
desired number of allocations, which is one.
To avoid much of the overhead pertaining to the creation of these allocated
`GISignalInfo` objects, introduce a new function that inspects the signal
blobs directly and returns an allocated `GISignalInfo` object just for the
matching signal. The function is largely a copy-and-paste of `gi_base_info_find_vfunc()`,
which does the same thing, only for virtual functions.
See https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/504
This follows the usage in the glib codebase and recommendations at
main/docs/toolchain-requirements.md
It also fixes a build warning with ancient gcc 4.8:
../girepository/gitypelib-internal.h:202:1: warning:
no previous prototype for ‘_blob_is_registered_type’ [-Wmissing-prototypes]
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
It’s unclear why there was a hole in this. Let’s keep things less
confusing by eliminating it.
Fixes commit 453dd4be9e906078a7fb7466819ce1876a629a45.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It's gio-windows-2.0.pc, not gio-win32-2.0.pc.
Otherwise, we get warnings/errors where the package cannot be located
but since we are linking to the same GIO library file, this did not
manifest itself.
When building a typelib, the values of constants need to be converted
from a string format (from the GIR) to a binary format. This is
currently done, for all numeric types, using `g_ascii_strto*()`
functions, but with minimal validation. String values which are not
representable as binary numbers are either silently truncated or
clamped.
`-Wfloat-conversion` has flagged that this happens for floats – a
double-precision return from `g_ascii_strtod()` is implicitly cast down
to a float.
While we should ideally have some better error handling so that
conversion to a typelib fails if a constant is not representable in the
typelib, this is a problem for *all* numeric types and not just `float`,
so add an explicit cast to ignore the error for now.
In practice there probably isn’t a problem for any numeric types here,
as there should be validation of the string value when the GIR is
generated anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
libgirepository is not needed by most of the modules, but it is needed
by the `g-ir-scanner` generated dumper program. If we don’t explicitly
include the local version of it here, Meson will implicitly link against
it anyway, and that might pull in a different version, or try to link
against a half-built local version as the build ordering dependency tree
won’t reflect this relationship.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3401
As a special case, keep the historical behaviour of treating gchar
as being signed, both on platforms where it is genuinely signed (for
example x86 Linux) and where it is unsigned (for example ARM, s390x
and PowerPC Linux). Changing gchar to use INTEGER_ALIAS would have a
regression risk, so if we want to do that, it should be as a separate
change.
No functional change intended.
Signed-off-by: Simon McVittie <smcv@debian.org>
It’s currently completely untested. Let’s add a few basic tests so that
adding more tests in future is easier.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In macOS compilation fails with the following error:
```
In file included from ../girepository/tests/autoptr.c:23:
../girepository/girffi.h:30:10: fatal error: 'ffi.h' file not found
```
Relocation is a common scenario in macOS applications and frameworks.
This commit provides a mechanism to support relocations by inferring
the typelib dir from the path of the loaded image libgirepository-1.0.dylib.
For historical reasons, some doc blocks are included in an ancillary
file. Add it to the list of sources parsed by g-ir-scanner, to increase
the coverage of various macros.
Fixes: #3372
Since we are now building introspection files for GLib while building
GLib, so we want to make sure that we indeed load the freshly-built
DLLs when running g-ir-scanner, so we add the various needed subdirs
(and if needed, subprojects), to set the GI_EXTRA_BASE_DLL_DIRS
envvar so that g-ir-scanner will look for the newly-built GLib DLLs.
Ideally, upstream g-ir-scanner will need to be updated accordingly to do
something similar to what we are doing here, but this is needed until
the time that we require a g-ir-scanner that contains the update.
This will also fix the g-ir-scanner erroring out when there is no
pre-existing GLib on the system, as the needed DLLs are now found.
Related issue: https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/499
Related MR in G-I:
https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/458
It's just better than a list of strings for various reasons, but mostly
here it allows also to avoid copying the lists but making the
ownership clearer through references
In this way the module can survive without that the parser is fully
alive.
At the moment a module has not a ref-count system, but this makes things
clearer when we return the module from a parser.
In case the node was pushed to a non-empty node stack, then we were not
tracking it in the entries list, and so nothing was freeing it on
destruction.
As per this, once parsing is done, we can free it or we'd leak.
