cmake @3.4.0 build fails if /Library/Frameworks/libcurl.framework exists

[bertlhf (Bert Fitié)]

cmake-3.4.0 - build succeeded on my MacBook, but failed on my iMac

[bertlhf (Bert Fitié)]

_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log

[mdeaudelin (Mathieu Deaudelin-Lemay)]

You have a version of cURL in /Library/Frameworks/libcurl.framework that does not contain 64-bit symbols, or which was built with different options than those required. The cmake build script is picking it up rather than the MacPorts version in /opt/local, which causes the build to fail.

Please remove the conflicting framework and try again.

[ryandesign (Ryan Carsten Schmidt)]

That's true. See wiki:FAQ#libraryframeworks.

However, this problem comes up so frequently that I would like to see it fixed in the cmake port. It should be possible, and is a best practice, to inform the cmake build system which libcurl (and libz and libbz2 and libarchive and so on) we would like it to use, rather than letting it guess (wrongly).

[michaelld (Michael Dickens)]

I agree with Ryan that cmake finding dependencies outside of $prefix has been a PITA before & should just be fixed if we can reasonably do so. Thus, in r143049 I tweaked the settings in the macports.cmake settings file & hopefully these will take care of this issue for all dependencies. Can someone with the external Curl installed do a selfupdate & then test installing cmake to verify that it now works?

[kencu (Ken)]

four years of silence suggests this must have been fixed by the changes Michael committed.

Please reopen with new information if this is still an issue for you.