Does ./configure detect the compiler correctly as clang? I am surprised about the "-fast" error.
I had errors with the standard library (gnu-something) before, if clang was not running in c++ but in c mode. I don't know what apple is doing though. Deal.II currently compiles with clang 3.1 on linux. Can you compile a hello world c++ app using clang? On Tue, Aug 14, 2012 at 5:48 PM, Luca Heltai <[email protected]> wrote: > Cia Timo, > > I set the compilers to be CC=cc and CXX=c++, which on OS X are symbolic links > to clang. I've recompiled everything using your suggestion (CC=clang, > CXX=clang++), but nothing changed. > > :( > > L. > > -- > Luca Heltai <[email protected]> > http://people.sissa.it/~heltai/ > Scuola Internazionale Superiore di Studi Avanzati > Phone: +39 040 3787 449, Office: 732 > -- > There are no answers, only cross references > > On Aug 14, 2012, at 11:19, Timo Heister <[email protected]> wrote: > >> Hi Luca, >> >> you set your compiler as CXX=clang CC=clang ? You need to do >> "CXX=clang++ CC=clang" instead. >> >> On Tue, Aug 14, 2012 at 4:57 PM, Luca Heltai <[email protected]> wrote: >>> Dear All, >>> >>> after trying to find a workaround for a bug in OS X Mountain Lion, I tried >>> switching to the clang compiler (which seems to be Apple's favorite, now). >>> >>> I have version >>> >>> Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn) >>> Target: x86_64-apple-darwin12.0.0 >>> Thread model: posix >>> >>> The entire library compiles with no problems (except a warning during >>> compilation of umfpack: >>> >>> clang: warning: argument unused during compilation: '-fast' >>> >>> ) but as soon as linking is attempted, I get a lot of undefined references >>> to what seem to be gnu related headers... >>> >>> The first one is: >>> >>> Undefined symbols for architecture x86_64: >>> "__gnu_cxx::__verbose_terminate_handler()", referenced from: >>> (anonymous >>> namespace)::preload_terminate_dummy::preload_terminate_dummy() in >>> base_exceptions.o >>> >>> And then virtually all boost functions: >>> >>> "std::basic_string<wchar_t, std::char_traits<wchar_t>, >>> std::allocator<wchar_t> >::data() const", referenced from: >>> >>> boost::archive::basic_binary_iprimitive<boost::archive::naked_binary_iarchive, >>> char, std::char_traits<char> >::load(std::basic_string<wchar_t, >>> std::char_traits<wchar_t>, std::allocator<wchar_t> >&) in >>> base_boost_serialization.o >>> >>> boost::archive::basic_binary_iprimitive<boost::archive::binary_iarchive, >>> char, std::char_traits<char> >::load(std::basic_string<wchar_t, >>> std::char_traits<wchar_t>, std::allocator<wchar_t> >&) in >>> base_boost_serialization.o >>> >>> etc. >>> >>> Anybody has had experience with making late versions of clang and deal.II >>> to work? >>> >>> L. >>> >>> -- >>> Luca Heltai <[email protected]> >>> http://people.sissa.it/~heltai/ >>> Scuola Internazionale Superiore di Studi Avanzati >>> Phone: +39 040 3787 449, Office: 732 >>> -- >>> There are no answers, only cross references >>> >>> _______________________________________________ >>> dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii >> >> >> >> -- >> Timo Heister >> http://www.math.tamu.edu/~heister/ > -- Timo Heister http://www.math.tamu.edu/~heister/ _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
