Meson incorrectly assumes shared libraries even after detecting only static libraries

[amyspark]

Describe the bug

By default, prefer_static is false i.e. it will prefer shared libraries to static ones when setting up link paths. However, this is not something that PkgConfigCLI.libs supports.

This makes the linking process easy to break; assume a library b which depends on a, build both static-only, and then try to link to b in a separate project.

The link process will fail with missing symbol errors corresponding to all used symbols of a, e.g.

[2/2] Linking target temp2.exe
FAILED: temp2.exe temp2.pdb
"link"  /MACHINE:x64 /OUT:temp2.exe temp2.exe.p/main.c.obj "/release" "/nologo" "/DEBUG" "/PDB:temp2.pdb" "C:/Users/Amalia/Desktop/Rachel/meson-library-temp/temp2/../install/lib/libb.a" "/SUBSYSTEM:CONSOLE" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" "comdlg32.lib" "advapi32.lib"
libb.a(b.c.obj) : error LNK2019: unresolved external symbol foo referenced in function boo
temp2.exe : fatal error LNK1120: 1 unresolved externals

To Reproduce

Clone this repo: https://github.com/amyspark/meson-bug-shared-static, build and install temp1 with -Ddefault_library=static. Then build temp2 setting -Dpkg_config_path=<install path of temp1>/lib/pkgconfig.

Expected behavior

After Meson finds that b is available statically only, it must repeat the pkg-config query with --static so that Libs.private and Requires.private are properly applied.

system parameters

• Is this a cross build or just a plain native build (for the same computer)? No
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) Windows 10 22H2
• what Python version are you using e.g. 3.8.0 3.10.7
• what meson --version 1.6.0
• what ninja --version if it's a Ninja build 1.10.2

cc @nirbheek