diff options
| author | Sam James <sam@gentoo.org> | 2025-10-17 16:40:07 +0100 |
|---|---|---|
| committer | Eli Schwartz <eschwartz93@gmail.com> | 2025-10-31 01:13:28 -0400 |
| commit | 4f43a402504aa57ffa3f7b6091f5fdccfd2a3000 (patch) | |
| tree | 37a8498c3b90d7bf3aeaa6b2798f0867ac4513bd /run_single_test.py | |
| parent | 373cc823b009c5a0ceb06c462d656ec510a2505b (diff) | |
| download | meson-4f43a402504aa57ffa3f7b6091f5fdccfd2a3000.tar.gz | |
Always check if found libraries are linkable
We don't always check if a library is actually linkable because of concerns
that a library may not be standalone, so linking against it may still have
unresolved references. We can workaround that by building a shared library
as a test rather than an executable, and in fact we already do that in a
bunch of cases since bb5f2ca3da821d7a8e865cd55a8d5d638e0aab22.
This comes up in particular with Fedora and dependency('atomic') because
on x86_64, they provide a libatomic.so linker script (so our file existence
check passes), but trying to use it later on will fail if the backing package
isn't installed.
_get_file_from_list has not been deleted because the Ninja backend's
guess_library_absolute_path uses it. We might be able to change it to
also use a link test but I've left that alone.
Test notes:
* The _test_all_naming unittest has been tweaked because we were using a
blank file rather than an actual shared library, which (as expected),
now fails.
* I've also added a test for dependency('atomic') providing a result that
can actually be linked against. I've not made it check generally whether
dependency('atomic') finds something when we expect to (at least for now)
as it'll involve some CI whack-a-mole.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2352531
Bug: https://github.com/mesonbuild/meson/issues/14946
Closes: https://github.com/mesonbuild/meson/issues/10936
Diffstat (limited to 'run_single_test.py')
0 files changed, 0 insertions, 0 deletions
