Open ReenigneArcher opened 3 weeks ago
I wonder if cmake unity build causes the multiple definition issue - the same path relocation symbols come from openssl and curl.
The undefined reference issue can be fixed with proper compiler flags -DNGHTTP2_STATICLIB -DNGHTTP3_STATICLIB
. I think those should be handled by pkgconfig file and shall do some experiments.
Thanks for looking into this so quickly, much appreciated!
There are another issue causing broken linkage: both libcrypto.a
and libcurl.a
are having objects from pathtools.c
. #5074 #8955
If someone is statically linking those libraries, what's the best way to ignore the duplicated symbols?
There are another issue causing broken linkage: both
libcrypto.a
andlibcurl.a
are having objects frompathtools.c
Yeah, I have provided the same reason above but I can not reproduce that issue with simple program. The following command compiles a example program statically linked with curl library.
cc -static $(pkgconf -cflags -static libcurl) curl-8.8.0/docs/examples/simple.c $(pkgconf -libs -static libcurl) -lws2_32 -lz
It requires the pkgconfig changes as provided in the linked pull request.
Static linking reveals another issue. I can not run the statically compiled program.
$ ./a.exe
curl_easy_perform() failed: Problem with the SSL CA cert (path? access rights?)
Probably path relocation does not work with static linking.
lazka, could the multiple definition issue be fixed if pathtools.c functions are moved to pathtools.h and are made static?
@Biswa96 I think this will work.
I have fixed the undefined references issue with fixes in pkgconfig files and can not reproduce the multiple definition error with simple curl example. Please wait for others to fix it.
Still getting
undefined reference to `__imp_curl_easy_setopt'
w/ mingw-w64-curl-8.8.0-8
Is CURL_STATICLIB
macro defined?
Is
CURL_STATICLIB
macro defined?
Looks like only in the expected *_STATIC_CFLAGS
in my CMake cache...
Seeing the same problem when linking an application with libcurl. -2 worked, -8 fails wit the above error.
Could you reproduce the issue with a minimal example with CURL_STATICLIB
macro defined for static linking? That symbol does exist in both static library and import library.
$ nm /ucrt64/lib/libcurl.dll.a | grep curl_easy_setopt
0000000000000000 I __imp_curl_easy_setopt
0000000000000000 T curl_easy_setopt
$ nm /ucrt64/lib/libcurl.a | grep curl_easy_setopt
0000000000081d40 T curl_easy_setopt
But I don't want to link statically 😅 Or is it expected that applications always statically link to libcurl now?
is it expected that applications always statically link to libcurl now?
No, it is not expected. This issue is about static linking so I assumed that. Could you compile this example program? https://github.com/curl/curl/blob/curl-8_8_0/docs/examples/simple.c It uses curl_easy_setopt function.
No I am using a more complex application.
I solved it as follows: instead of adding CURL_LIBS to my target's link libraries, I now link with CURL::libcurl
While that works, it was surprising that it broke out of the blue.
Now I do think this way is more correct, so I did learn something new today!
I solved it as follows: instead of adding CURL_LIBS to my target's link libraries, I now link with CURL::libcurl
That could be due to migration from autotools to cmake which is not related to this issue. See this commit https://github.com/msys2/MINGW-packages/commit/db8fd75ce7834f456a2dbf832c3751d0ce04993e
Interesting! It was certainly that in my case, hopefully it can help others if they run into it and find this issue. Cheers!
Confirming that -2 worked, and -7 doesn't for shared library linking, and requires the switch to CURL::libcurl
target instead of CURL_LIBRARIES
. IMHO both should still work for shared linking.
-7 doesn't for shared library linking, and requires the switch to
CURL::libcurl
target instead ofCURL_LIBRARIES
.
When building cURL with CMake, it will generates a CURLConfig.cmake
config which could be used by find_package()
, and this won't set CURL_LIBRARIES
like the FindCURL.cmake
module, so you need to set(CURL_LIBRARIES CURL::libcurl)
or .find_package(CURL MODULE)
See <https://cmake.org/cmake/help/book/mastering-cmake/chapter/Finding Packages.html>.
UPDATE: find_package(CURL MODULE)
won't work, because https://cmake.org/cmake/help/latest/module/FindCURL.html#curl-cmake. Scary logic, when I say module, I am not meaning config, why they are doing such scary thing?
When building cURL with CMake...
That's besides the point - a client app can't possibly know how curl was built a priori, so this change in behaviour is not welcome.
FindCURL CMake builtin module already defines an IMPORTED Module CURL::libcurl
New in version 3.12.
This module defines IMPORTED target CURL::libcurl, if curl has been found.
Also:
New in version 3.17.
If CURL was built using the CMake buildsystem then it provides its own CURLConfig.cmake
file for use with the find_package() command's config mode.
This module looks for this file and, if found, returns its results with no further action.
Set CURL_NO_CURL_CMAKE to ON to disable this search.
I get all that. Still saying CURL_LIBRARIES
shouldn't have broken, as FindCURL
still claims it will produce a valid one, regardless of how curl was built:
CURL_LIBRARIES
List of libraries when using curl.
I get all that. Still saying
CURL_LIBRARIES
shouldn't have broken, asFindCURL
still claims it will produce a valid one, regardless of how curl was built:CURL_LIBRARIES List of libraries when using curl.
Report the issue to CMake.
Report the issue to CMake.
Looks like we're not the first to notice:
https://gitlab.kitware.com/cmake/cmake/-/issues/24580 https://gitlab.kitware.com/cmake/cmake/-/issues/25994
For the duplicate symbols one solution is to add this line to lib/CMakeLists.txt
, as part of 0001-Make-cURL-relocatable.patch
:
set_source_files_properties(pathtools.c PROPERTIES SKIP_UNITY_BUILD_INCLUSION ON)
As for the missing __imp_*
libcurl symbols and CURL_LIBRARIES
left empty, here's a patch proposal that may help:
https://github.com/curl/curl/pull/13897
Just to add, I am statically linking curl which has slightly different variable names, like:
CURL_STATIC_INCLUDE_DIRS
CURL_STATIC_LIBRARY_DIRS
CURL_STATIC_LIBRARIES
@vszakats would your PR to curl handle these as well?
@ReenigneArcher No. Are these variables also filled by CMake's FindCURL.cmake
?
@vszakats Accoring to https://cmake.org/cmake/help/latest/module/FindCURL.html, no.
We're using pkg_check_modules(CURL REQUIRED libcurl)
which does populate them.
@vszakats Accoring to https://cmake.org/cmake/help/latest/module/FindCURL.html, no.
We're using
pkg_check_modules(CURL REQUIRED libcurl)
which does populate them.
Ah okay, that looks like a different problem.
This other PR may help with the above: https://github.com/curl/curl/pull/13911
Description / Steps to reproduce the issue
Curl is failing to statically link since ~2 days ago.
mingw-w64-ucrt-x86_64-curl
Expected behavior
Curl properly links as it did previously.
Actual behavior
The initial error (~2 days ago) was many
undefined references
(https://github.com/LizardByte/Sunshine/actions/runs/9278791852/job/25530652407?pr=2604#step:7:501)But now it is many
multiple definition
(https://github.com/LizardByte/Sunshine/actions/runs/9278791852/job/25604282363?pr=2604#step:7:504)Verification
Windows Version
Microsoft Windows Server 2019, 10.0.17763 (GitHub hosted runner)
MINGW environments affected
Are you willing to submit a PR?
I would if I knew what the fix was.