Hi Byungsuk, > On 2 Oct 2018, at 11:39, Byungsuk Lee <[email protected]> wrote: > > Dear Jonas and Oliver, > > Thank you for your replies. I wanted to give you a sort of status report > regarding the use of ARTS on my Mac. > > 1) I checked ARTS/build/CMakeCache.txt and confirmed that no conda package > was used, other than CONDA_PROG:FILEPATH=... which I think is irrelevant. > > 2) I tried compiling with gcc/g++ instead, both from Homebrew and from > manually installing tar.gz files from the gnu website for a few different > versions, but the same irregular invalid t_field errors in OEM happened. > Plus, at the cmake stage, they constantly produced a failure message for > "Wno-return-type-c-linkage" as follows, about which I am curious why. This > doesn't happen with clang/clang++. > > ... > -- Performing Test CCFLAG_Wno-sign-conversion > -- Performing Test CCFLAG_Wno-sign-conversion - Success > -- Performing Test CXXFLAG_Wno-sign-conversion > -- Performing Test CXXFLAG_Wno-sign-conversion - Success > -- Performing Test CCFLAG_Wno-unknown-pragmas > -- Performing Test CCFLAG_Wno-unknown-pragmas - Success > -- Performing Test CXXFLAG_Wno-unknown-pragmas > -- Performing Test CXXFLAG_Wno-unknown-pragmas - Success > -- Performing Test CCFLAG_Wno-return-type-c-linkage > -- Performing Test CCFLAG_Wno-return-type-c-linkage - Failed > -- Performing Test CXXFLAG_Wno-return-type-c-linkage > -- Performing Test CXXFLAG_Wno-return-type-c-linkage - Failed > -- Performing Test CCFLAG_Wno-strict-overflow > -- Performing Test CCFLAG_Wno-strict-overflow - Success > -- Performing Test CXXFLAG_Wno-strict-overflow > -- Performing Test CXXFLAG_Wno-strict-overflow - Success > ...
Some compilers don't support the flag no-return-type-c-linkage. That is totally fine and the reason that we test its existence with cmake before enabling it. > 3) Instead of the clang/clang++ from Homebrew llvm with which I initially > installed ARTS, I thought I could instead try using Mac's command line tools > clang/clang++ (AppleClang v10), but they failed at the make stage with the > following error which I am not sure how to tackle. > > ... > [ 43%] Linking CXX executable make_auto_workspace_h > Undefined symbols for architecture x86_64: > "___kmpc_critical", referenced from: > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in file.cc.o > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in file.cc.o > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > ... > "___kmpc_end_critical", referenced from: > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in file.cc.o > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in file.cc.o > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > ... > "___kmpc_global_thread_num", referenced from: > ArtsOut& operator<<<std::__1::basic_string<char, > std::__1::char_traits<char>, std::__1::allocator<char> > >(ArtsOut&, > std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> > const&) in arts.cc.o > ArtsOut& operator<<<char [35]>(ArtsOut&, char const (&) [35]) in > file.cc.o > ArtsOut& operator<<<char [75]>(ArtsOut&, char const (&) [75]) in > file.cc.o > ArtsOut& operator<<<char [2]>(ArtsOut&, char const (&) [2]) in file.cc.o > ArtsOut& operator<<<my_basic_string<char> >(ArtsOut&, > my_basic_string<char> const&) in file.cc.o > ArtsOut& operator<<<char [3]>(ArtsOut&, char const (&) [3]) in file.cc.o > ArtsOut& operator<<<long>(ArtsOut&, long const&) in file.cc.o > ... > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > make[2]: *** [src/make_auto_workspace_h] Error 1 > make[1]: *** [src/CMakeFiles/make_auto_workspace_h.dir/all] Error 2 > [ 43%] Building CXX object > src/CMakeFiles/test_gridded_fields.dir/test_gridded_fields.cc.o > [ 43%] Building CXX object src/CMakeFiles/test_legendre.dir/test_legendre.cc.o > [ 43%] Linking CXX executable test_legendre > [ 43%] Built target test_legendre > [ 43%] Linking CXX executable test_gridded_fields > [ 43%] Built target test_gridded_fields > make: *** [all] Error 2 > ... This is interesting. The __kmpc_* Symbols come from the Intel Math Kernel Library. These errors usually indicate that the Intel Threading library was enabled, but the Intel OpenMP Library was not linked. Which makes sense because Apple's Clang does not support OpenMP. But we might be on to something here. The Intel MKL should involved here at all. Do you have an Intel compiler set up in your PATH? > 4) I tried using Homebrew lapack instead of Mac's default > Accelerate.framework but the same irregular OEM error happened. > > I have tried several things as above hoping to pinpoint where the error stems > from (compiler, package, or something else?) but am so far unsuccessful and > encountered additional errors that I hope someone could explain. Thank you. Are you sure that you're actually compiling against Lapack / Accelerate and not accidentally always against MKL? What you're seeing in 3) makes me a bit suspicious. Can you please check with 'otool -L src/arts' which libraries your ARTS executable is actually linked against? cheers, /oliver _______________________________________________ arts_users.mi mailing list [email protected] https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_users.mi
