STIR
STIR copied to clipboard
UCL
Clang 9.0.1 on OSX and CMake failure
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 https://github.com/UCL/STIR/blob/a005fd711658af2bed0b88f7f725965c8ae74c25/CMakeLists.txt#L44-L46
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?
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?
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)
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.
From this link, perhaps the Conda build is running Sierra (10.12) or High Sierra (10.13)? Can you choose a newer OSX image?
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?
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.
@rijobro, I've updated the release_4.0 branch https://github.com/UCL/STIR/commit/c287e70015be284fd5d2901b0f24cd88ca37b9ad to set the policy. Sorry, forgot to do a PR.
Can you check if this works for you?
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!
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.
Unfortunately, conda's build still says the same, so https://github.com/UCL/STIR/commit/c287e70015be284fd5d2901b0f24cd88ca37b9ad didn't help. Oh well.
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.
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?
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
Quite unlikely this is a STIR problem. Seems something wrong with your XCode. maybe need a reinstall after brew upgrade or whatever?
Similar issue reported here and is related to the Xcode toolchain being corrupted: https://github.com/kaldi-asr/kaldi/issues/4078#issuecomment-647279029
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. https://github.com/PointCloudLibrary/pcl/issues/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.
Others struggle with the above errors as well. https://github.com/Homebrew/homebrew-core/pull/59146#issuecomment-672867298 thinks it might be a VTK-bug.
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 https://github.com/conan-io/conan-center-index/pull/3977 the default mode of apple-clang 12 (and 10) is C++03. Features in STIR seem to require C++11 or later.
I'm going to close this, as it seems very outdated. By the way, we do require c++-11 now.