CURL fails to build on macOS 10.15.2

[jothepro]

• I've read Brief overview section and do understand basic concepts. [Yes]
• I've read F.A.Q. section and there is no solution to my problem there. [Yes]
• I've read Code of Conduct, I promise to be polite and will do my best at being constructive. [Yes]
• I've read Reporting bugs section carefully. [Yes]
• I've checked that all the hunter_add_package/find_package API used by me in the example is the same as in documentation. [Yes]
• I'm using latest Hunter URL/SHA1. [Yes]

• I've created SSCCE reproducing the issue:

# CMakeLists.txt

cmake_minimum_required(VERSION 3.2)

include(cmake/HunterGate.cmake)
HunterGate(
    URL "https://github.com/cpp-pm/hunter/archive/v0.23.240.tar.gz"
    SHA1 "ca19f3769e6c80cfdd19d8b12ba5102c27b074e0"
    LOCAL
)

project(hunter-curl
    VERSION 1.0.0
    LANGUAGES CXX
)

hunter_add_package(CURL)
find_package(CURL CONFIG REQUIRED)

• I've created SSCCE GitHub repository to reproduce the issue:
  • https://gitlab.com/jothepro/hunter-curl

Here is the log until first error reported by Hunter, option HUNTER_STATUS_DEBUG is ON:

• https://pastebin.com/EbcmutJA

I've checked that the first error in logs IS NOT external.build.failed. [Yes]

• I'm building on macOS 10.15.2 (Catalina).
• I'm using cmake from homebrew
• CMake version: 3.16.2
• Xcode version: 11.3

• I'm not using toolchain

I'm using the next command line on generate step:

cmake -H. -Bbuild -GXcode -DHUNTER_STATUS_DEBUG=true

---

Additional Information

• I have been building CURL successfully on macOS 10.15 previously. After some while and a few updates on macOS, cmake & hunter the build has started failing. I can not say for sure what caused it.
• I've been doing some research on the issue. During configuration cmake tries to link a test-library against -lsocket, which does not exist on macOS because socket-interfaces are part of libc. This might be a hint that the build is not configured correctly for macOS. Output from CMakeError.log: https://pastebin.com/41JAVN2V
• It would be very helpful to have someone else reproduce the issue.
• Rolling back to an older version of CURL (7.60.0-p0) does not help.
• Rolling back to an older version of cmake (3.15.5) does not help.
• Rolling back to an older version of macOS or XCode is not possible.
• I've not yet tried to build CURL from the official upstream, to check if it is an issue with the CURL project. Let me know if that would be helpful.

[rbsheth]

Hmm, I've also been building CURL on macOS 10.15 successfully. I'll try reproducing this when I update my Mac.

[jothepro]

Update: I tried to build CURL from submodule to investigate the issue:

hunter_config(CURL GIT_SUBMODULE "thirdparty/curl")

In the given folder I cloned the hunterized curl repository, which should be exactly the same code that is checked out by hunter.
This now builds successfully. The CURL version is the same (7.60.0-DEV)

As I remove the reference to the submodule and let hunter pull the sources, the build fails again.
Maybe this is some kind of a weird caching issue? I deleted .hunter in the user-dir multiple times, doesn't help. Am I missing some cache that might be screwed up?

[rbsheth]

Interesting. Do you have remote cache download enabled? If so, try disabling that.

[jothepro]

Actually I'm not sure. I think it is not enabled by default, is it?
Right now I have a strong feeling that something else is fundamentally wrong with my project setup. Even with the described workaround I need to configure curl in the project that I posted for reproduction, because it still fails to build in my original project. Once a successful build is in the local cache, I can use it from my original project. Im confused and will definitely have to dig deeper into the issues linked in here once I find time for that.

[Bjoe]

@jothepro I'm not 100% sure but I think you run in the same issue like #147

I saw that you are using
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang as compiler. Try to use /usr/bin/clang as compiler.
There are the "same" compiler and they are using the same toolchain path ... see my output:

iMac:~ joergboehme$ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
iMac:~ joergboehme$ /usr/bin/clang --version
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

but there is "something" different!

I absolutely don't know what are different but I tried with other "opensource" projects and it works with /usr/bin/clang and not with /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang ....
Maybe somebody can tell me what are the different between /usr/bin/clang and /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang ... would be nice to know :-)

[Bjoe]

@jothepro I found your problem ....

As workaround:
Remove in your CMakeList.txt line11 LANGUAGES CXX and remove your hunter build id (.hunter/_Base/<Hunter-ID>/), then it works ....

Why?
Here in detail:

If you set in project cmake command the LANGUAGES then only the specified language compiler is verified via cmake. In your example it was only the C++ compiler.
At the end, hunter is verified if the ABI was correct detected via cmake. CMAKE_CXX_ABI_COMPILED is an undocumented property from cmake and is set when you get following output:

...
-- Detecting CXX compiler ABI info - done
...

This means, in your example, the C compiler is not verified and CMAKE_C_ABI_COMPILED is set as empty value.

To build third-party libs in hunter faster, hunter is save this result in the "cache" file (see in your .hunter/_Base/<Hunter-ID>/<Toolchain-ID>/<Config-id>/cache.cmake).
This means in the curl project, where the C compiler is enabled and CMAKE_C_ABI_COMPILED is set via the cache file and cmake is not execute the ABI detection then in hunter the verification is failing

In my opinion, we should not save any "cmake environment" when it is not successful!
My idea is to add an if statement in hunter_create_cache_file line 110 like:

if(CMAKE_${lang}_ABI_COMPILED)
  hunter_status_debug("ABI forwarding: CMAKE_${lang}_ABI_COMPILED = ${CMAKE_${lang}_ABI_COMPILED}")
    file(
        APPEND
        "${temp_path}"
        "set(CMAKE_${lang}_ABI_COMPILED \"${CMAKE_${lang}_ABI_COMPILED}\" CACHE INTERNAL \"\")\n"
    )
endif()

@rbsheth and @bkotzz what do you think ?

[Bjoe]

or maybe we remove this DEFINED from hunter_create_cache_file line 70

[jothepro]

@Bjoe wow thanks for your in-depth explanations! I also figured out after a while that my LANGUAGES definition was the real problem. Not caching the "corrupted" state would have helped me to find the real issue faster I think, so I'd appreciate these changes. ☺️

[jothepro]

@rbsheth @bkotzz What do you think of the changes that @Bjoe proposes? Otherwise I guess I will close this issue, the original problem is solved for me.

[rbsheth]

I'd be okay with @Bjoe's suggestion provided that it doesn't slow down builds considerably.

[Bjoe]

Ok let me do this... hopefully I will find a "time slot" ....