The weak symbol resolution doesn’t seem to work (see
https://gitlab.gnome.org/GNOME/glib/-/jobs/3265405):
```
Undefined symbols for architecture x86_64:
"___lsan_enable", referenced from:
_g_leak_sanitizer_is_supported in gutils.c.o
"___lsan_ignore_object", referenced from:
_g_ignore_leak in gquark.c.o
_g_ignore_leak in gthreadpool.c.o
_g_ignore_leak in gutils.c.o
_g_leak_sanitizer_is_supported in gutils.c.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
See !3672
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
`test-generated.txt` is listed in `test.gresource.xml`, so it needs to
be specified as a dependency in the `custom_target()` which uses
`test.gresource.xml`.
Fixes intermittent build failures like:
```
FAILED: gio/tests/test.gresource
/builds/GNOME/glib/_build/gio/glib-compile-resources --compiler=gcc --target=gio/tests/test.gresource --sourcedir=/builds/GNOME/glib/gio/tests --sourcedir=/builds/GNOME/glib/_build/gio/tests --internal ../gio/tests/test.gresource.xml
../gio/tests/test.gresource.xml: Failed to locate test-generated.txt in any source directory.
```
See !3671 and #3163.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
This reverts commit 0b9900e4e7.
The dependency was added in the wrong place: `test-generated.txt` is
needed when compiling `test.gresource`, not when compiling the test
which ultimately uses that gresource.
See !3671 and #3163.
GLib ignores various leaks that we don't consider as such (like the
default gio modules) via the LSAN public interface, however those cases
are always ignored when using a non-ASAN compiled glib is used by an
ASAN-compiled binary.
This makes all the GLib-related programs to fail because of false
positive leaks.
To avoid this, use the gcc extension for weak linking so that we can
control ASAN and LSAN only if the symbols they provide are actually
available at runtime.
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
Make sure that each C file in `girepository/` includes its corresponding
header file (if such a file exists).
This ensures that the first declaration the compiler sees for each
function contains the symbol visibility macros. This fixes symbol export
(`dllexport`) on Windows platforms.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
`gthash.c` transitively includes it.
Most of this commit is just moving variables around so `gi_visibility_h`
is defined early enough in the file. The moved code has not been changed.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
The pkg-config file sets the include directory to the level above
`girepository/`, just like with GIO, GObject and GModule.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
These are all custom-written, including a load of research in `git log`
to find the copyright holders for `girepository/meson.build` and
`girepository/gi-dump-types.c`.
With this, `reuse lint` raises no complaints about the `girepository/`
directory.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
Add the SPDX license runes to all the files which have an obvious
copyright header already. This is a mechanical edit.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Helps: #3155
