-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
gcc dependency library from the forward link #501
Conversation
Can you tell us what error you are seeing without this fix? The order should be (and is currently) |
on my environment generate : |
This could happen indeed with librtmp-enabled builds. |
Yes. |
How are you building curl? The only way I can see that happening is if you have a pkgconfig file for openssl that is specifying ssl and crypto static without specifying gdi32 and you are doing a static build of libcurl. It appears that it's not easy to build libcurl static with a static pkg-config OpenSSL, at least in the case of mingw. To remedy that we can support the What wouldn't hurt on our end is to move the gdi32 check to the beginning of the ssl block before anything else (in other words gdi32 will appear at least once after any ssl libs) and allow PKG_CONFIG to set pkg-config location and options in curl's Please let me know if this works for you however you normally build: |
Yes. I am doing a static build of libcurl. Configure:
Error:
Use your code (https://github.com/jay/curl/compare/master...jay:fix_static_openssl_mingw?expand=1). It works fine.
Configure2:
linker output:
While your code to work properly, but I still think this place needs to change the order. Because gdi32 is the basic library, which does not depend on other libraries, other libraries(except openssl) may be directly or indirectly dependent on it. And gcc forward link libraries. So there remains a need to change the order. |
There's really a broader issue here which is what is our responsibility if a user is making a static libcurl and wants to link static dependencies as well. If the user wants to link static dependency foo, which may depend on bar and baz, how would we know it depends on bar and baz? One can use the We are making a best guess for OpenSSL in the case of mingw/msys by including gdi32 in the case of ssl. If any other library is dependent on gdi32 we should address that separately; or not based on what we think about the first issue. In that case I would move the test for gdi32 earlier than I made it now so it would not be specific to ssl. Both of our proposed changes make it so that gdi32 is only added if ssl, so both would be incorrect in the case that gdi32 could be a dependency for other static libraries. The commit I've proposed addresses what you reported in the least disruptive manner, however I'm open to other ideas. |
libcurl is not directly dependent on gdi32, so there isn't need to test gdi32(The library depend on gdi32 to deal with the gdi32). http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html |
Linking statically basically means you need to provide the dependencies manually as they're next to impossible for us to figure out and provide. |
- If mingw ssl make sure -lgdi32 comes after ssl libs - Allow PKG_CONFIG to set pkg-config location and options Bug: #501 Reported-by: Kang Lin
gcc dependency library from the forward link。so gdi32 put back。