Skip to content
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

Clang 9.0.1 on OSX and CMake failure #531

Closed
KrisThielemans opened this issue May 9, 2020 · 23 comments
Closed

Clang 9.0.1 on OSX and CMake failure #531

KrisThielemans opened this issue May 9, 2020 · 23 comments
Assignees
Milestone

Comments

@KrisThielemans
Copy link
Collaborator

KrisThielemans commented May 9, 2020

The conda build for OSX now fails with

No known features for CXX compiler
  "Clang"
  version 9.0.1.

I suspect that this is because 9.0.1 is brand-new, and the installed CMake 3.17.0 doesn't know it yet, although I'm not sure.

However, I found a similar post http://cmake.3232098.n2.nabble.com/No-known-features-for-CXX-compiler-warning-with-custom-Clang-td7594752.html which says we should set CMP0025.
But then I'm not sure what we need at

STIR/CMakeLists.txt

Lines 44 to 46 in a005fd7

if((${CMAKE_CXX_COMPILER_ID} MATCHES "AppleClang") OR
(APPLE AND ${CMAKE_SYSTEM_NAME} MATCHES "Darwin" AND
${CMAKE_CXX_COMPILER_ID} MATCHES "Clang"))

@rijobro
Copy link
Collaborator

rijobro commented May 19, 2020

Sorry, I don't know Conda and am not sure how you want me to debug this. Do you just want me to try and build locally with CMake 3.17 and Clang 9.0.1?

@rijobro
Copy link
Collaborator

rijobro commented May 19, 2020

Can you pick the compiler version that Conda uses? If you could just set it to an earlier version, this problem would go away, right?

@KrisThielemans
Copy link
Collaborator Author

This is an existing problem that just happens to be thrown up on the conda tests. It doesn't have anything to do with conda really. Also, forcing older compilers with conda is going to get us into trouble at some point (you don't want to conda install STIR and get a lot of old compiler stuff...).

Anyway, test is: modify STIR's top-level CMakeList.txt to set CMP0025 (can't remember if this has to be done before the "required CMake version" or after), and test it if still compiles for you. If not, modify the lines above (but it doesn't look likely)

@rijobro
Copy link
Collaborator

rijobro commented May 19, 2020

when I run clang --version, I get:

Apple clang version 11.0.3 (clang-1103.0.32.59)
Target: x86_64-apple-darwin19.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

So it seems I'm using 11.0.3, not 9.0.1.

@rijobro
Copy link
Collaborator

rijobro commented May 19, 2020

From this link, perhaps the Conda build is running Sierra (10.12) or High Sierra (10.13)? Can you choose a newer OSX image?

@rijobro
Copy link
Collaborator

rijobro commented May 19, 2020

Also the link in your first post (http://cmake.3232098.n2.nabble.com/No-known-features-for-CXX-compiler-warning-with-custom-Clang-td7594752.html) says that he's using a brew version of clang (presumably because that was the best way back then to use OpenMP). I'm guessing that you're not using a brew installed version?

@KrisThielemans
Copy link
Collaborator Author

KrisThielemans commented May 19, 2020

Thanks Richard. I don't really want to get into conda stuff too much. I know conda installs its own compilers and is independent of brew, and even most system files these days.

The way I understand the nabble post is that the CMP0025 policy is recommended, as otherwise a new CMake will/might fall back to outdated behaviour (as our minimum requirements are very old). So, I suggest we just try that, commit it, and hope it resolves the conda problem. If not, we'll wait a while until conda's CMake has caught up with their clang.

So, if you don't mind creating a PR on top if release_4.0 (as I have to make a 4.0.2 anyway) with the policy set (at least, if it works for you), and we see what happens.

@KrisThielemans
Copy link
Collaborator Author

@rijobro, I've updated the release_4.0 branch c287e70 to set the policy. Sorry, forgot to do a PR.

Can you check if this works for you?

@rijobro
Copy link
Collaborator

rijobro commented May 22, 2020

Works fine for me and all tests pass.

@KrisThielemans
Copy link
Collaborator Author

great. phew! Just waiting for Travis then, and then I'll tag 4.0.2. Then merge that onto release_4. I'll then create a new PR to merge release_4 onto master. There's likely some changes needed in the scatter code for the shared_ptr<const...>. Would you be able to have a look at that?

Time to merge Palak's PR onto release_4 then!

@rijobro
Copy link
Collaborator

rijobro commented May 22, 2020

There's likely some changes needed in the scatter code for the shared_ptr<const...>. Would you be able to have a look at that?

Sure, let me know when you've created the PR and i'll check it.

@KrisThielemans
Copy link
Collaborator Author

Unfortunately, conda's build still says the same, so c287e70 didn't help. Oh well.

@KrisThielemans
Copy link
Collaborator Author

Also observed by @robbietuk with brew ITK.

@robbietuk
Copy link
Collaborator

Had a working version of STIR. Installed ITK with brew, this updated a lot of dependancies (including python 3.7 -> 3.8) requiring a reinstall of STIR.

@KrisThielemans
Copy link
Collaborator Author

sure, updating "system" files generally means wiping existing CMake configurations. You can try to get round this by deleting cached settings (-UPYTHON\* etc) but it is generally not worth it. Note that upgrading a compiler definitely means removing all CMake stuff.

So, are you saying this worked then on a new install?

@robbietuk
Copy link
Collaborator

It seems the issue was with the cached settings. Creating a fresh install allowed for generate to work.
However errors imeditately on make

ccmake ../../STIR


roberttwyman@Roberts-MBP build % make 
Scanning dependencies of target buildblock
[  0%] Building CXX object src/buildblock/CMakeFiles/buildblock.dir/Array.cxx.o
In file included from /Users/roberttwyman/bin/STIR/STIR/src/buildblock/Array.cxx:34:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/Array.h:41:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/NumericVectorWithOffset.h:36:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/VectorWithOffset.h:34:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/common.h:103:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:317:9: error: no member named 'signbit' in the global namespace
using ::signbit;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:318:9: error: no member named 'fpclassify' in the global namespace
using ::fpclassify;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:319:9: error: no member named 'isfinite' in the global namespace; did you mean 'finite'?
using ::isfinite;
      ~~^
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include/math.h:749:12: note: 'finite' declared here
extern int finite(double)
           ^
In file included from /Users/roberttwyman/bin/STIR/STIR/src/buildblock/Array.cxx:34:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/Array.h:41:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/NumericVectorWithOffset.h:36:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/VectorWithOffset.h:34:
In file included from /Users/roberttwyman/bin/STIR/STIR/src/include/stir/common.h:103:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:320:9: error: no member named 'isinf' in the global namespace
using ::isinf;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:321:9: error: no member named 'isnan' in the global namespace
using ::isnan;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:322:9: error: no member named 'isnormal' in the global namespace
using ::isnormal;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:323:9: error: no member named 'isgreater' in the global namespace
using ::isgreater;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:324:9: error: no member named 'isgreaterequal' in the global namespace
using ::isgreaterequal;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:325:9: error: no member named 'isless' in the global namespace
using ::isless;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:326:9: error: no member named 'islessequal' in the global namespace
using ::islessequal;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:327:9: error: no member named 'islessgreater' in the global namespace
using ::islessgreater;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:328:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:329:9: error: no member named 'isunordered' in the global namespace
using ::isunordered;
      ~~^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:640:26: error: no template named 'numeric_limits'
    bool _FloatBigger = (numeric_limits<_FloatT>::digits > numeric_limits<_IntT>::digits),
                         ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:640:60: error: no template named 'numeric_limits'
    bool _FloatBigger = (numeric_limits<_FloatT>::digits > numeric_limits<_IntT>::digits),
                                                           ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:641:18: error: no template named 'numeric_limits'
    int _Bits = (numeric_limits<_IntT>::digits - numeric_limits<_FloatT>::digits)>
                 ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:641:50: error: no template named 'numeric_limits'
    int _Bits = (numeric_limits<_IntT>::digits - numeric_limits<_FloatT>::digits)>
                                                 ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:646:17: error: no template named 'numeric_limits'
  static_assert(numeric_limits<_FloatT>::radix == 2, "FloatT has incorrect radix");
                ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:649:25: error: no template named 'numeric_limits'
  return _FloatBigger ? numeric_limits<_IntT>::max() :  (numeric_limits<_IntT>::max() >> _Bits << _Bits);
                        ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
make[2]: *** [src/buildblock/CMakeFiles/buildblock.dir/Array.cxx.o] Error 1
make[1]: *** [src/buildblock/CMakeFiles/buildblock.dir/all] Error 2
make: *** [all] Error 2

@KrisThielemans
Copy link
Collaborator Author

Quite unlikely this is a STIR problem. Seems something wrong with your XCode. maybe need a reinstall after brew upgrade or whatever?

@robbietuk
Copy link
Collaborator

Agreed, I will clean up the caches and I am updating xcode.

@robbietuk
Copy link
Collaborator

robbietuk commented Aug 5, 2020

Similar issue reported here and is related to the Xcode toolchain being corrupted:
kaldi-asr/kaldi#4078 (comment)

Reinstalling Xcode and Comand Line Tools leads to the same error.

Similar issues were found here but many of the solutions didnt work for me. PointCloudLibrary/pcl#2601

Uninstalling Xcode but keeping CLT allowed for compilation...

e: For me the issue was fixed when CMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk instead of
CMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk. Therefore this is a mac issue due to conflics between Comand line tools and Xcode SDK libraries. Simply replacing the line was not enough and this is not a perminante fix.

ITK is also causing some issues but that is seperate.

@KrisThielemans
Copy link
Collaborator Author

Others struggle with the above errors as well. Homebrew/homebrew-core#59146 (comment) thinks it might be a VTK-bug.

@KrisThielemans
Copy link
Collaborator Author

as I have no clue how to address this, I'll postpone it for later

@KrisThielemans KrisThielemans modified the milestones: v4.1, v5.0 Nov 14, 2020
@erin-computerhead
Copy link

Not sure if this is related but in order to get STIR 4.0.1 to build on Mac OSX 11.6 I had to explicitly set the C++ compiler version in the top-level CMakeLists.txt file as follows:

  if (APPLE)
      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++ -std=c++14")
  endif()

According to conan-io/conan-center-index#3977 the default mode of apple-clang 12 (and 10) is C++03. Features in STIR seem to require C++11 or later.

@KrisThielemans KrisThielemans modified the milestones: v5.0, v5.1 Mar 18, 2022
@KrisThielemans
Copy link
Collaborator Author

I'm going to close this, as it seems very outdated. By the way, we do require c++-11 now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants