New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: change import library name on non Visual Studio platform #6225
Conversation
|
@jzakrzewski so only .dll.a ? |
@vtorri yes, if we want the change at all. I'm afraid, however, that I'm not qualified to say if the rename should be applied at all. For that I'd rather hear what others think. |
ok, i'll wait for comments, then |
Almost all the libraries for Visual Studio use .lib, and we should keep doing that. At the time possibly nobody thought about using cmake with other compilers in Windows. MinGW does use .a extension so it seems reasonable to use it there. Perhaps we should just let the linker pick, I'm not sure why we're not doing that... |
@jay i've tried to remove that part and compile with MSYS2 + mingw-w64 git diff :
script to compile
cross compilation file (otherwise cmake considers it's a UNIX system) :
installation output
|
also, a bit later in this CMakeLists.txt i see
again, cmake is tweaked a bit. Is it really necessary ? |
I don't know. We will need cmake people (contributors familiar with cmake) to chime in. Another possibility is in Visual Studio since you can have a static lib and an implicit lib maybe there is a naming conflict, unlike mingw. So libcurl.lib (static) and libcurl_imp.lib (dll) |
My uderstanding is that the name conflict between the static and import library (thank you MS for that) is why we rename the thing. Most libraries I know actually just use different name for the static library so there's no conflict and all the names are simply generated by the build system. Here the sole fact that we have "curl" and "libcurl" targets is problematic. |
afaics, you can't build both static and library with the project generated by cmake. toplevel cmake, at line 1472 and later shows this. So i don't think the name is a problem to paraphrase Pedro Alves, one of the dev of gcc on Windows : dll are good on Windows (he implies no static lib on Windows) |
That's correct. Many projects try work around this limitation by providing two CMake targets - one for static and one for dynamic library. But I think curl is rather concerned about installation - with the default naming scheme on Windows it's impossible to to install static and dynamic versions because the import library will conflict with the static one. |
@jzakrzewski what do you think we should do here, is this PR necessary? |
Strictly necessary - probably not. It's, however, good to do things in "more standard" way. This renaming is only necessary because curl went the route of keeping static library name the same as dynamic. Renaming anything at this point is a trade-off between breaking something and enabling something else. From CMake code perspective the change is OK. I don't touch Windows unless I absolutely have to, so I cannot say if this change brings more benefits or sorrow. |
Ok thanks for your input, I've tagged it next-feature-window. |
@vtorri to follow up on this, what you are saying is .dll.a is applied without your change, is that correct? Then maybe it should be just if(MSVC) to address only that. |
without my patch, libcurl_imp.lib is always installed (VS or msys2) what is important, for me, is that with msys2, or when cross-sompiling on linux for windows, we can use pkg-config --cflags --libs libcurl also note that with msys2 and the autotools, libcurl.dll.a is installed : libtool: install: /usr/bin/install -c .libs/libcurl.dll.a E:/Documents/programmes_x64/msys2/opt/ewpi2_64/lib/libcurl.dll.a |
what i mean is can we remove the .dll.a since according to your earlier post that is added automatically for msys if(WIN32)
if(BUILD_SHARED_LIBS)
- # Add "_imp" as a suffix before the extension to avoid conflicting with the statically linked "libcurl.lib"
- set_target_properties(${LIB_NAME} PROPERTIES IMPORT_SUFFIX "_imp.lib")
+ if(MSVC)
+ # Add "_imp" as a suffix before the extension to avoid conflicting with the statically linked "libcurl.lib"
+ set_target_properties(${LIB_NAME} PROPERTIES IMPORT_SUFFIX "_imp.lib")
+ endif()
endif()
endif() |
@jay i've extracted latest release of curl and i've done your change. Seems good : -- Installing: E:/Documents/programmes_x64/msys2/opt/curl2/lib/libcurl.dll.a you can commit your patch to git, i'll close this PR once done thank you |
@jay so ? |
It's tagged next-feature-window so that means when the feature window opens in a week or so I will add it. |
- Use _imp.lib suffix only for Microsoft's compiler (MSVC). Prior to this change library suffix _imp.lib was used for the import library on Windows regardless of compiler. With this change the other compilers should now use their default suffix which should be .dll.a. This change is motivated by the usage of pkg-config on MSYS2. Indeed, when 'pkg-config --libs libcurl' is used, -lcurl is passed to ld. The documentation of ld on Windows : https://sourceware.org/binutils/docs/ld/WIN32.html lists, in the 'direct linking to a dll' section, the pattern of the searched import library, and libcurl_imp.lib is not there. Closes #6225
👉 View analysis in DeepCode’s Dashboard | Configure the bot |
Thanks |
This change is motivated by the usage of pkg-config on MSYS2.
Indeed, when 'pkg-config --libs libcurl' is used, -lcurl is
passed to ld. The documentation of ld on Windows :
https://sourceware.org/binutils/docs/ld/WIN32.html
lists, in the 'direct linking to a dll' section, the pattern
of the searched import library, and libcurl_imp.lib is not there.