I believe this problem is connected to an incorrect mixture of libraries in the computer that was used to compile the 4.4 version (which used some files from MacOSX10.5.sdk and some from MacOSX10.6.sdk).
I tried to compile the gcc compiler myself on this mac, and I know for a fact that it is a nightmare, so I'm not surprised... I believe the main issue is a buggy support for 64 bits architecture in 10.5, which got better in 10.6. If you mix the two things, nasty subtle bugs will haunt your code, and this is what happened with gcc 4.4 from hpc. This is only my educated guess, so don't take this for granted. I just cannot think of better explanations... ;-) Luca. On 24/nov/2009, at 09.44, Andrew McBride wrote: > Hi Luca > > Thanks a lot for your assistance. I installed gcc 4.5 from the site you > recommended below (i was using the download from http://hpc.sourceforge.net/ > which provided gcc 4.4) and all appears to be working fine. > > I'm still puzzled as to why there were issues with the other versions of gcc > that Scott and I had tried and why this problem only arose when moving to > snow leopard. > > Andrew > > On 24 Nov 2009, at 12:45 AM, Luca Heltai wrote: > >> The one I used is >> >> http://prdownloads.sourceforge.net/hpc/gcc-snwleo-intel-bin.tar.gz?download >> >> What is the output of >> >> /usr/local/bin/gcc -v ? >> >> The one you show as output of gcc -v is the default that ships with apple, >> not the one in /usr/local/bin (unless /usr/local/bin comes first in the >> path). During your builds of deal.II programs, as long as you include >> $D/common/Make.global_options in your makefile (which is true for all >> example makefiles), you should be using the one you used at configure time. >> >> The output of my gcc is the following: >> >> /usr/local/bin/gcc -v >> Using built-in specs. >> Target: x86_64-apple-darwin10 >> Configured with: ../gcc-4.5-20090910/configure >> --enable-languages=fortran,c++ --host=x86_64-apple-darwin10 >> --build=x86_64-apple-darwin10 >> Thread model: posix >> gcc version 4.5.0 20090910 (experimental) (GCC) >> >> obtained by downloading gcc+gfortran with the above link. >> >> >> I'm doing a brand new installation, right now, using this command line: >> >> ./configure CXX=/usr/local/bin/g++ CC=/usr/local/bin/gcc >> F77=/usr/local/bin/gfortran >> Configuring deal.II version 6.3.pre >> checking build system type... i386-apple-darwin10.2.0 >> checking host system type... i386-apple-darwin10.2.0 >> checking target system type... i386-apple-darwin10.2.0 >> >> ---------------- configuring C/C++ compilers ---------------- >> checking for gcc... /usr/local/bin/gcc >> checking for C compiler default output file name... a.out >> checking whether the C compiler works... yes >> checking whether we are cross compiling... no >> checking for suffix of executables... >> checking for suffix of object files... o >> checking whether we are using the GNU C compiler... yes >> checking whether /usr/local/bin/gcc accepts -g... yes >> checking for /usr/local/bin/gcc option to accept ISO C89... none needed >> checking for /usr/local/bin/gcc... /usr/local/bin/gcc >> checking whether we are using the GNU C++ compiler... yes >> checking whether /usr/local/bin/g++ accepts -g... yes >> checking for /usr/local/bin/g++... /usr/local/bin/g++ >> C++ compiler is gcc4.5 (subversion gcc4.5.0) >> >> I can compile everything with no problem, including TBB (to answer Jon's >> question). I do get the warning on -Wno-long-double unrecognized, but this >> has gone so far unnoticed by my system. >> >> ... >> =====base=============debug======MT== path_search.cc >> source/path_search.cc:102:1: warning: unused parameter ‘open_mode’ >> cc1plus: warning: unrecognized command line option "-Wno-long-double" >> =====base=============debug======MT== polynomial.cc >> ... >> >> Just to test, I ran step-21, and it went through with no problems. >> >> Luca. >> >> >> -- >> Luca Heltai <luca.hel...@unipv.it> >> http://people.sissa.it/~heltai/ >> Scuola Internazionale Superiore di Studi Avanzati >> Phone: +39 040 3787 449, Office: 255 >> -- >> There are no answers, only cross references. >> >> >> >> >> >> >> On 23/nov/2009, at 21.57, Andrew McBride wrote: >> >>> Hi >>> >>> I've recompiled deal using the gcc 4.4 from the HPC on MacOSX site (not >>> sure if there is a 4.5 available on the site) and still get the same >>> problems with the dynamic_cast. Here is some information from the configure >>> log: >>> >>> bash-3.2$ ./configure CXX=/usr/local/bin/g++ CC=/usr/local/bin/gcc >>> F77=/usr/local/bin/gfortran >>> --with-doxygen=/Applications/Doxygen.app/Contents/Resources/doxygen >>> Configuring deal.II version 6.3.pre >>> checking build system type... i386-apple-darwin10.0.0 >>> checking host system type... i386-apple-darwin10.0.0 >>> checking target system type... i386-apple-darwin10.0.0 >>> >>> ---------------- configuring C/C++ compilers ---------------- >>> checking for gcc... /usr/local/bin/gcc >>> checking for C compiler default output file name... a.out >>> checking whether the C compiler works... yes >>> checking whether we are cross compiling... no >>> checking for suffix of executables... >>> checking for suffix of object files... o >>> checking whether we are using the GNU C compiler... yes >>> checking whether /usr/local/bin/gcc accepts -g... yes >>> checking for /usr/local/bin/gcc option to accept ISO C89... none needed >>> checking for /usr/local/bin/gcc... /usr/local/bin/gcc >>> checking whether we are using the GNU C++ compiler... yes >>> checking whether /usr/local/bin/g++ accepts -g... yes >>> checking for /usr/local/bin/g++... /usr/local/bin/g++ >>> C++ compiler is gcc4.4 (subversion gcc4.4.1) >>> checking if the compiler is built for MPI... no >>> checking whether compiler has a flag to support C++1x... yes >>> checking for std::array... yes >>> checking for std::condition_variable... no >>> checking for std::function and std::bind... yes >>> checking for std::bind works with rvalues... no >>> checking for std::shared_ptr... yes >>> checking for std::thread... no >>> checking for std::mutex... no >>> checking for std::tuple... yes >>> checking whether C++1x support is complete enough... no >>> checking whether qualifiers in return types lead to a warning... no >>> checking for std::advance warning... no >>> checking whether we can use -Wno-long-double... yes >>> checking whether -ggdb works... yes >>> C compiler is gcc-4.4 >>> >>> Luca, perhaps you could post your configure log for comparison? >>> >>> Once deal is compiled, how is the compiler chosen to compile applications >>> using the deal library (such as the examples)? Does deal use the compilers >>> you specify when configuring? The output of gcc -v is as follows: >>> >>> Using built-in specs. >>> Target: i686-apple-darwin10 >>> Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking >>> --enable-werror --prefix=/usr --mandir=/share/man >>> --enable-languages=c,objc,c++,obj-c++ >>> --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib >>> --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 >>> --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 >>> --target=i686-apple-darwin10 >>> Thread model: posix >>> gcc version 4.2.1 (Apple Inc. build 5646) >>> >>> >>> If I check the Make.global_options it would indicate the HPC MacOSX >>> libraries are used when compiling deal.II applications: >>> >>> ###################################################### >>> >>> D = /Users/andrewmcbride/lib/real_deal_svn/deal.II >>> CXX = /usr/local/bin/g++ >>> GXX-VERSION = gcc4.4 >>> GXX-VERSION-DETAILED = gcc4.4.1 >>> CC = /usr/local/bin/gcc >>> CC-VERSION = gcc4.4 >>> SHLIBLD = /usr/local/bin/g++ >>> SHLIBFLAGS = -dynamiclib >>> AR = /usr/bin/ar >>> RANLIB = /usr/bin/ranlib >>> LDFLAGS = -L/Users/andrewmcbride/lib/real_deal_svn/deal.II/lib >>> -Wl,-rpath,/Users/andrewmcbride/lib/real_deal_svn/deal.II/lib -m64 -ldl >>> F77 = /usr/local/bin/gfortran >>> F77-VERSION = gcc4.4 >>> F77LIBS = -lgfortran >>> >>> >>> Thanks >>> Andrew >>> >>> On 23 Nov 2009, at 4:26 PM, Scott Miller wrote: >>> >>>> I have tried gcc 4.0 & 4.2 that ship with 10.6, and also gcc 4.3.4 from >>>> macports; they all suffer from the same problem. >>>> >>>> -Scott >>>> >>>> On Nov 23, 2009, at 3:55 AM, Luca Heltai wrote: >>>> >>>>> I have mac os 10.6, but I don't see this problem. I use the gcc 4.5 >>>>> compiler distributed by the HPC on mac os x website (which also has >>>>> gfortran). >>>>> >>>>> Luca. >>>>> >>>>> -- >>>>> Luca Heltai <luca.hel...@unipv.it> >>>>> http://people.sissa.it/~heltai/ >>>>> Scuola Internazionale Superiore di Studi Avanzati >>>>> Phone: +39 040 3787 449, Office: 255 >>>>> -- >>>>> There are no answers, only cross references. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 23/nov/2009, at 07.31, Andrew McBride wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> I'm having the same issues on my mac after upgrading to Mac OS 10.6. So >>>>>> for example when attempting to run step-21: >>>>>> >>>>>> macs-mac:step-21 andrewmcbride$ bash >>>>>> bash-3.2$ make run >>>>>> ============================ Running step-21 >>>>>> Number of active cells: 1024 >>>>>> Number of degrees of freedom: 4160 (2112+1024+1024) >>>>>> >>>>>> -------------------------------------------------------- >>>>>> An error occurred in line <807> of file <source/fe/fe_system.cc> in >>>>>> function >>>>>> void dealii::FESystem<dim, spacedim>::compute_fill(const >>>>>> dealii::Mapping<dim, spacedim>&, const typename >>>>>> dealii::Triangulation<dim, spacedim>::cell_iterator&, unsigned int, >>>>>> unsigned int, const dealii::Quadrature<dim_1>&, >>>>>> dealii::CellSimilarity::Similarity, typename dealii::Mapping<dim, >>>>>> spacedim>::InternalDataBase&, typename dealii::Mapping<dim, >>>>>> spacedim>::InternalDataBase&, dealii::FEValuesData<dim, spacedim>&) >>>>>> const [with int dim_1 = 2, int dim = 2, int spacedim = 2] >>>>>> The violated condition was: >>>>>> dynamic_cast<const Quadrature<dim> *>(quadrature_base_pointer) != 0 >>>>>> The name and call sequence of the exception was: >>>>>> ExcInternalError() >>>>>> Additional Information: >>>>>> (none) >>>>>> >>>>>> It may have something to do with the use of gcc 4.2.1 under snow leopard. >>>>>> >>>>>> Andrew >>>>>> >>>>>> On 22 Nov 2009, at 4:27 AM, Scott T. Miller wrote: >>>>>> >>>>>>>> Uh, in the code, we have >>>>>>>> const Subscriptor* quadrature_base_pointer = &quadrature; >>>>>>>> ... >>>>>>>> Assert (dynamic_cast<const Quadrature<dim>*> >>>>>>>> (quadrature_base_pointer) != 0, >>>>>>>> ExcInternalError()); >>>>>>>> cell_quadrature >>>>>>>> = static_cast<const Quadrature<dim>*> >>>>>>>> (quadrature_base_pointer); >>>>>>>> >>>>>>>> So quadrature_base_pointer is a Subscriptor*. The assert checks that it >>>>>>>> really is a pointer to the Subscriptor base class of Quadrature, and >>>>>>>> after >>>>>>>> so checking we use the static case to get the Quadrature. What do you >>>>>>>> suggest to do here? >>>>>>> >>>>>>> The Subscriptor works fine, but the errors occur in the Assert >>>>>>> (dynamic_cast<...>...) part. My "solution" (quotes necessary) was to >>>>>>> replace the dynamic_cast with static_cast. This is not a real solution >>>>>>> though, merely a work-around for already working code; we really have >>>>>>> no idea the validity of the cast (if we did, the Assert would be >>>>>>> unnecessary).... I don't really know what the underlying problem is, >>>>>>> but the dynamic_cast's such as this one give problems on Mac OS 10.6. >>>>>>> I'm definitely open to any other ideas. >>>>>>> >>>>>>> >>>>>>>>> This is the same >>>>>>>>> problem Pietro had an a previous mail. >>>>>>>> >>>>>>>> I seem to suffer from amnesia -- can you point me to his mail in which >>>>>>>> he >>>>>>>> had this problem? >>>>>>> >>>>>>> Sorry I didn't reply to the already opened issue, but I'm having >>>>>>> problems getting the mailing list emails through. >>>>>>> http://www.mail-archive.com/dealii@dealii.org/msg00916.html >>>>>>> >>>>>>> >>>>>>> -Scott >>>>>>> _______________________________________________ >>>>>>> dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii >>>>>> >>>>>> _______________________________________________ >>>>>> dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii >>>>> >>>>> >>>> >>> >> > _______________________________________________ dealii mailing list http://poisson.dealii.org/mailman/listinfo/dealii
