Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
gcc dependency library from the forward link #501
Can you tell us what error you are seeing without this fix? The order should be (and is currently)
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.
Use your code (https://github.com/jay/curl/compare/master...jay:fix_static_openssl_mingw?expand=1). It works fine.
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).