lightvector / KataGo

GTP engine and self-play learning in Go
https://katagotraining.org/
Other
3.56k stars 564 forks source link

katago 1.5.0 failed to build on high-sierra os #298

Open chenrui333 opened 4 years ago

chenrui333 commented 4 years ago

👋 It looks like the latest release build failed to build on high-sierra machine.

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:313/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:313:9: error: no member named 'signbit' in the global namespace
:9using ::signbit;:
       ~~^
error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:314:9:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/cmath:314:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
      ~~^
 error: no member named 'fpclassify' in the global namespace
using ::fpclassify;

Please kindly take a look. Thanks!

relates to https://github.com/Homebrew/homebrew-core/pull/59166

lightvector commented 4 years ago

Hmm, do you understand what the problem is? According to your link, it successfully builds on some versions, and only fails on one version, and the failure is caused simply by including <cmath>?

Googling around it seems like this is maybe due to apple moving around where system headers are located, and various people in many different projects have run into this?

https://stackoverflow.com/questions/58628377/catalina-c-using-cmath-headers-yield-error-no-member-named-signbit-in-th https://github.com/PointCloudLibrary/pcl/issues/2601

I don't understand Mac well enough to know what to do here. Can you test things and find a fix? It looks like your homebrew configuration here already has at least one cmake hack for mac that it passes in on the command line when invoking cmake - is there another hack that needs to be added? Or does cmake need to be updated? It would seem quite strange to me if perpetually cmake on mac produced g++ invocations that pointed to the wrong system headers.

lightvector commented 4 years ago

Oh, apologies, I just realized you're not the original person who helped set KataGo up on homebrew, it seems like you're someone just reporting the issue. If so, thanks!

I remain a little stuck on what to do, and don't know exactly how I would go about trying to either reproduce or fix this, not having any experience with either osx or xcode. @dwt or anyone else - any thoughts here? If it really is just a os-version-specific error relating to the compiler not being able to include <cmath> due to some configuration of paths, maybe there is some simple hack that fixes it.

dwt commented 4 years ago

I remain a little stuck on what to do, and don't know exactly how I would go about trying to either reproduce or fix this, not having any experience with either osx or xcode. @dwt https://github.com/dwt or anyone else - any thoughts here? If it really is just a os-version-specific error relating to the compiler not being able to include due to some configuration of paths, maybe there is some simple hack that fixes it.

I’m sorry to say, but I don’t have access to 10.13 anymore - so I’m a bit lost on how to debug this. I am subscribing to the original homebrew bug in order to try to help debug this.

lightvector commented 4 years ago

So what's confusing me is that there seems to be nothing that has changed from v1.4.5 to v1.5.0 that should cause this?

The errors appear to be something involving <cmath> when building cpp/core/fancymath.cpp. Stuff in core doesn't depend on stuff outside of core, and git diff -r v1.4.5 v1.5.0 --stat shows that nothing inside cpp/core was changed. The CMakeLists.txt was changed, but the changes in there seem fairly harmless and irrelevant if not attempting to build the Eigen or CUDA backends.

lightvector commented 4 years ago

Oh, looks like https://github.com/Homebrew/homebrew-core/pull/51949 might be another instance of this.

Although the katago 1.5.0 homebrew configuration does already have std_cmake_args. So maybe the problem is something else? Does unsetting HOMEBREW_SDKROOT work, like it did as a hack for cmake itself?