There are some flavors of MIPS ABIs, such like r6 vs legacy,
nan2008 vs nan1985 etc.
The `cc -r` may not produce the correct elf binaries.
So let's skip this test for MIPS.
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
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
The gio/tests/socket-client.c doesn't use GSocketClient, which makes the
filename confusing. What the file actually tests is the GSocket. Rename
it to socket-testclient.c
The corresponding GSocket server test file naming doesn't conflict with other
class names, but rename it to socket-testserver.c for consistency.
Closes#2855
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
This test is fairly pointless, but puts the infrastructure in place for
adding more tests for `GFdoNotificationBackend` in upcoming commits.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Do not search in path for snapctl to avoid it to be potentially
overridden by changing the PATH env variable.
Still allow testing by using an ifdef to check if we're building for the
test files or not.
Test all the snap cases and the unknown sandbox one.
We need to use different test processes as we initialize the portal
type early enough that it can't be changed later.
This reverts commit 19353017a7.
The freedesktop SDK, which is used by gnome-build-meta, only has Meson
0.63. Bumping GLib’s Meson dependency to 0.64 means that, at the moment,
GLib is not buildable in gnome-build-meta and hence can’t be tested in
nightly pipelines against other projects, etc.
That’s bad for testing GLib.
It’s arguably bad that we’re restricted to using an older version of
Meson than shipped by Debian Testing, but that’s a separate discussion
to be had.
Revert the Meson 0.64 dependency until the freedesktop SDK ships Meson ≥
0.64. This also means reverting the simplifications to use of
`gnome.mkenum_simple()`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3077#note_1601064
Because Meson complains about using `configure_file(copy: true)`.
Includes improvements by Xavier Claessens.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Do not use can_run_host_binaries() as it returns true even though
custom_target() does not currently correctly wrap target-built
tool binaries with exe_wrapper so they can be run on the host.
See https://github.com/mesonbuild/meson/issues/11029
We need to make sure that such binaries are built and available at test time
or we may fail some tests requiring them (directly or through desktop file).
As per this, and because now generated desktop files are available both
at build and install time, don't skip some tests we were used to, but
actually enforce they are running.
We have some test programs on which some tests depend on, for example
appinfo-test is a tool that is used by the desktop-app-info tests.
So test can now have an 'extra_programs' key where the extra program
names can be included.
This could have been handled manually via 'depends', but this allows
to avoid repeating code and be sure that all is defined when extra
programs targets are checked.
We were generating .desktop files with different content when installed
tests were enabled, and thus making impossible to test some cases
because there was no built file until installed.
To avoid this, always generate both versions of desktop files while
install only the one containing the install path prefix if needed.
