rust: Linking with C static libraries in subdirectories fails

[gfxstrand]

We're running into issues building Mesa with 1.3.0rc2: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/51253570

With 1.2.3, meson generates the following build rule:

 ARGS = --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type rlib --edition=2021 -g --crate-name mesa_rust_gen --emit dep-info=src/gallium/frontends/rusticl/mesa_rust_gen.d --emit link -Aclippy::all -Aunused_unsafe -Anon_camel_case_types -Anon_snake_case -Anon_upper_case_globals -o src/gallium/frontends/rusticl/libmesa_rust_gen.rlib -l static=gallium -l static=libmesaclc -l dylib=drm -l dylib=LLVM-17 -l dylib=z -l dylib=zstd -l dylib=unwind -l dylib=z -l dylib=zstd -l dylib=unwind -l dylib=clang-cpp -l dylib=LLVM-17 -l dylib=LLVMSPIRVLib -l dylib=SPIRV-Tools-opt -l dylib=SPIRV-Tools -l dylib=SPIRV-Tools-link -L src/gallium/auxiliary -L src/compiler/clc -L /usr/lib64 -L/usr/lib/gcc/x86_64-redhat-linux/13 -L/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64 -L/usr/lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/13/../../.. -L/usr/lib -L/lib -lstdc++

whereas meson 1.3.0rc2 generates the following:

 ARGS = --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type rlib --edition=2021 -g --crate-name mesa_rust_gen --emit dep-info=src/gallium/frontends/rusticl/mesa_rust_gen.d --emit link=src/gallium/frontends/rusticl/libmesa_rust_gen.rlib --out-dir src/gallium/frontends/rusticl/libmesa_rust_gen.rlib.p -Aclippy::all -Aunused_unsafe -Anon_camel_case_types -Anon_snake_case -Anon_upper_case_globals -l static:+verbatim=src/gallium/auxiliary/libgallium.a -l static:+verbatim=src/compiler/nir/libnir.a -l static:+verbatim=src/compiler/libcompiler.a -l static:+verbatim=src/util/libmesa_util.a -l static:+verbatim=src/util/libmesa_util_sse41.a -l static:+verbatim=src/util/blake3/libblake3.a -l static:+verbatim=src/c11/impl/libmesa_util_c11.a -l static:+verbatim=src/compiler/clc/liblibmesaclc.a -l static:+verbatim=src/compiler/spirv/libvtn.a -l dylib=drm -l dylib=LLVM-17 -l dylib=z -l dylib=zstd -l dylib=unwind -l dylib=z -l dylib=zstd -l dylib=unwind -l dylib=z -l dylib=zstd -l dylib=unwind -l dylib=clang-cpp -l dylib=LLVM-17 -l dylib=LLVMSPIRVLib -l dylib=SPIRV-Tools-opt -l dylib=SPIRV-Tools -l dylib=SPIRV-Tools-link -l dylib=z -l dylib=zstd -l dylib=unwind -L src/gallium/auxiliary -L src/compiler/nir -L src/compiler -L src/util -L src/util/blake3 -L src/c11/impl -L src/compiler/clc -L src/compiler/spirv -L /usr/lib64 -L/usr/lib/gcc/x86_64-redhat-linux/13 -L/usr/lib/gcc/x86_64-redhat-linux/13/../../../../lib64 -L/usr/lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/13/../../.. -L/usr/lib -L/lib -lstdc++

The important part seems to be -l static=gallium -L src/gallium/auxiliary vs. -l static=src/gallium/auxiliary -L src/gallium/auxiliary where meson 1.3.0rc2 is trying to provide a path in both places and then rustc can't find the library because the -l isn't relative to any of the -L.

[xclaesse]

Thanks for testing! Pretty sure it's a regression from #12367. It does lib = self.get_target_filename_for_linking(d) which includes the subdir part instead of just the basename.