cmake: fix libcurl.pc and curl-config library specifications

Letting CMake figure out where libraries are located gives you full
paths. When generating libcurl.pc and curl-config, getting libraries as
full paths is unusual when one expects to get a list of -l<libname>.

To meet expectations, an effort is made to convert the full paths into
-l<libname>, possibly with -L<libdir> before it.

Fixes #6169
Fixes #12748
Closes #12930
This commit is contained in:
Richard Levitte 2024-02-13 06:45:57 +01:00 committed by Daniel Stenberg
parent 6a13d4d75c
commit 296e855d36
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
2 changed files with 41 additions and 10 deletions

View file

@ -98,7 +98,6 @@ problems may have been fixed or changed somewhat since this was written.
15.3 unusable tool_hugehelp.c with MinGW
15.6 uses -lpthread instead of Threads::Threads
15.7 generated .pc file contains strange entries
15.8 libcurl.pc uses absolute library paths
15.11 ExternalProject_Add does not set CURL_CA_PATH
15.13 CMake build with MIT Kerberos does not work
@ -577,14 +576,6 @@ problems may have been fixed or changed somewhat since this was written.
See https://github.com/curl/curl/issues/6167
15.8 libcurl.pc uses absolute library paths
The libcurl.pc file generated by cmake contains things like Libs.private:
/usr/lib64/libssl.so /usr/lib64/libcrypto.so /usr/lib64/libz.so. The
autotools equivalent would say Libs.private: -lssl -lcrypto -lz
See https://github.com/curl/curl/issues/6169
15.11 ExternalProject_Add does not set CURL_CA_PATH
CURL_CA_BUNDLE and CURL_CA_PATH are not set properly when cmake's