handle file paths to libraries

[Be-ing]

Typically pkgconfig files specify cflags for linking with -L and -l,
however, pkgconfig files can also specify paths to library files. For
example, building Qt5 statically on macOS generates the following
pkgconfig file. Notice the absolute path to libqtpcre.a in Libs.private:

prefix=/Users/be/qt5-installed
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include

host_bins=${prefix}/bin
qt_config=debug_and_release release debug build_all c++11 c++14 c++17 c++1z concurrent dbus no-pkg-config reduce_exports release_tools static stl

Name: Qt5 Core
Description: Qt Core module
Version: 5.15.5
Libs: -L${libdir} -lQt5Core
Libs.private: -framework DiskArbitration -framework IOKit -lm -framework AppKit -framework Security -framework ApplicationServices -framework CoreServices -framework CoreFoundation -framework Foundation -lz /Users/be/sw/qt-everywhere-src-5.15.5/qtbase/lib/libqtpcre2.a
Cflags: -DQT_CORE_LIB -I${includedir}/QtCore -I${includedir}

Building Qt5 statically on macOS with vcpkg generates this pkgconfig
file which has a handful of file paths for libraries:

prefix=${pcfiledir}/../..

exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include/qt5

host_bins=${prefix}/tools/qt5/bin
qt_config=release c++11 c++14 c++17 c++1z concurrent dbus no-pkg-config reduce_exports static stl properties animation textcodec big_codecs codecs itemmodel proxymodel concatenatetablesproxymodel textdate datestring doubleconversion filesystemiterator filesystemwatcher gestures identityproxymodel library mimetype process statemachine regularexpression settings sharedmemory sortfilterproxymodel stringlistmodel systemsemaphore temporaryfile translation transposeproxymodel xmlstream xmlstreamreader xmlstreamwriter

Name: Qt5 Core
Description: Qt Core module
Version: 5.15.3

Libs: -L"${libdir}" -lQt5Core  -L"${prefix}/lib" -L"${prefix}/lib/manual-link" -framework DiskArbitration -framework IOKit -lm -framework AppKit -framework Security -framework ApplicationServices -framework CoreServices -framework CoreFoundation -framework Foundation ${prefix}/lib/libz.a -ldouble-conversion ${prefix}/lib/libicui18n.a ${prefix}/lib/libicutu.a ${prefix}/lib/libicuuc.a ${prefix}/lib/libicuio.a ${prefix}/lib/libicudata.a ${prefix}/lib/libpcre2-16.a -lzstd  ${prefix}/lib/libbz2.a ${prefix}/lib/libpng16.a ${prefix}/lib/libicui18n.a ${prefix}/lib/libicutu.a ${prefix}/lib/libicuuc.a ${prefix}/lib/libicuio.a ${prefix}/lib/libicudata.a ${prefix}/lib/libzstd.a
Cflags: -DQT_CORE_LIB -I"${includedir}/QtCore" -I"${includedir}"

[Be-ing]

I stumbled on this trying to statically link Qt built from vcpkg: KDAB/cxx-qt#174

[sdroege]

Looks good to me otherwise, thanks!

[Be-ing]

I'm not sure how to handle the build failure with Rust 1.30.0. Any suggestions how to keep this MSRV? Or raise the MSRV?

[sdroege]

I think we should just update the MSRV. It's not sustainable to stay at an older version if the whole ecosystem moved on already.

[nirbheek]

The file matching is incorrectly strict.

On windows if you're using MSVC or MinGW or Clang, you can link to: libfoo.a (static library built by Autotools with gcc or Meson with all compilers) or foo.lib (import library or static library with visual studio project files or cmake).

If you are using Clang or GCC you can also link to libfoo.dll.a (import library generated by GCC) or foo.dll (directly to the DLL; not recommended, but possible with GCC and Clang). You can generate foo.lib from libfoo.dll.a if you want your mingw-built libraries to be linkable by MSVC, and people do that.

Cygwin is a whole other beast, with different file naming.

[sdroege]

So maybe we should just search for (lib)?foo.(a|lib|lib.a|dll|dll.a) here and be done with it?

[Be-ing]

(lib)?foo.(a|lib|lib.a|dll|dll.a)

I'm not sure it would be that simple. It depends if rustc-link-lib wants the lib prefix or not and in which conditions.

[sdroege]

I guess this then needs checking what rustc actually expects/does here on Windows.

[nirbheek]

I suspect the linker used by rustc (lld or link or whatever) will accept whatever library you want to link to, if you use a full path.

[sdroege]

The problem is that rustc wants libraries separately as library-path / library-name AFAIU

[sdroege]

How should we proceed here? Are you planning to check what rustc is doing @Be-ing ?

[Be-ing]

I'll dig into the rustc source code to get a clearer idea of how it works, unless someone beats me to that.

[Be-ing]

Reading the rustc source code, I found that there is an undocumented verbatim modifier to the -l option specifically for this use case. Unfortunately, it is still unstable. 😞

[Be-ing]

A simpler solution: pass the file path to the linker with rustc-link-arg instead of rustc-link-lib.

[sdroege]

Ah that looks nicely simple, thanks!

[thomcc]

I think the correct way to implement this platform-specific behavior is using the TARGET environment variable.

It depends on the case. Each cfg comes through as an environment variable CARGO_CFG_{name}: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts. (Note that for multi-valued cfgs like target_feature or target_family this is a comma-separated list).

[Be-ing]

I think this is finally ready to merge.

[thomcc]

I'll try and do a more thorough review on Monday or Tuesday (presumably by then rust-lang/team#861 (comment) will be done and I'll be able to actually land it if it's good). Initial impressions are fairly positive.

[sdroege]

I'll go over this tomorrow but I'll wait then for @thomcc's review too early next week :)

[thomcc]

Looks good to me. I have one trivial nit (which is mostly nice to have and it could land without it).

Thanks for the great comments too, that made it much more straightforward to review.

[Be-ing]

Thanks for helping make this robust!

[Be-ing]

Could you publish a new release?

[sdroege]

Could you publish a new release?

Sure, done :)