From: Derek G. <fri...@gm...> - 2010-09-17 14:23:02
|
Has anyone around here been able to successfully use libMesh with XCode 3.2.3 on OSX? We've held off from upgrading to 3.2.3 for a while because of an incompatibility with the Intel compilers.... but that incompatibility was resolved so we have now tried 3.2.3... with epic failure. At this point I'm just using 3.2.3 with libMesh by itself. I'm not using the Intel compiler... nor Petsc. I'm just letting it use all the default stuff on OSX (including the built in MPI, etc). I'm not passing any options to libmesh's configure. So if you want to reproduce this... just "upgrade" to XCode 3.2.3, checkout libmesh do "./configure" and make in debug mode... then go build ex13 (just chosen by random) in debug mode and you should see something like: ######### Mesh Information: mesh_dimension()= EquationSystems n_systems()= ERROR: cannot convert system "Navier-Stokes" to requested type! [0] /Users/gastdr/projects/libmesh/include/systems/equation_systems.h, line 671, compiled Sep 17 2010 at 08:06:04 terminate called after throwing an instance of 'libMesh::LogicError' what(): Error in libMesh internal logic [Derek-Gastons-MacBook-Pro:13048] *** Process received signal *** [Derek-Gastons-MacBook-Pro:13048] Signal: Abort trap (6) [Derek-Gastons-MacBook-Pro:13048] Signal code: (0) [Derek-Gastons-MacBook-Pro:13048] [ 0] 2 libSystem.B.dylib 0x00007fff803e735a _sigtramp + 26 [Derek-Gastons-MacBook-Pro:13048] [ 1] 3 ??? 0x00007fff5fbfde00 0x0 + 140734799797760 [Derek-Gastons-MacBook-Pro:13048] [ 2] 4 libstdc++.6.dylib 0x00007fff84f465d2 __tcf_0 + 0 [Derek-Gastons-MacBook-Pro:13048] [ 3] 5 libobjc.A.dylib 0x00007fff819e4d3d _objc_terminate + 120 [Derek-Gastons-MacBook-Pro:13048] [ 4] 6 libstdc++.6.dylib 0x00007fff84f44ae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 [Derek-Gastons-MacBook-Pro:13048] [ 5] 7 libstdc++.6.dylib 0x00007fff84f44b16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 [Derek-Gastons-MacBook-Pro:13048] [ 6] 8 libstdc++.6.dylib 0x00007fff84f44bfc _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 [Derek-Gastons-MacBook-Pro:13048] [ 7] 9 ex13-dbg 0x0000000100022d71 _ZN7libMesh15EquationSystems10get_systemINS_15TransientSystemINS_20LinearImplicitSystemEEEEERT_RKSs + 869 [Derek-Gastons-MacBook-Pro:13048] [ 8] 10 ex13-dbg 0x0000000100005c9d main + 1646 [Derek-Gastons-MacBook-Pro:13048] [ 9] 11 ex13-dbg 0x00000001000026dc start + 52 ######### After looking at the various problems for the past few days it appears to be having trouble dynamic casting things... but I cannot see why. BUT... that's not the only problem. Notice the weirdness where the "Mesh Information" block didn't get printed completely. Some of the examples will run just fine.. but exhibit weird behavior like incomplete printing of information, etc. All in all... it's total weirdness... and I just want to make sure we're not the only ones seeing it. I saw this morning that there is an XCode 3.2.4 out as of a week ago... so I'm going to check that out today... but looking over the release notes I don't see anything that would lead me to believe that this is fixed. I'll report back. If 3.2.4 doesn't work I'm probably just going to have to downgrade to 3.2.2. That's the situation we've been in for a while... but it is trouble because we have to tell all of our customers with Macs NOT to upgrade to 3.2.3 (which the OSX software update thing will happily tell them to do all the time). So it would be nice if we could boil this down to something that XCode is doing wrong so I can send it off to my Apple contacts so this can get fixed once and for all. Derek |
From: Derek G. <fri...@gm...> - 2010-09-17 14:34:03
|
Ok - another data point here... if I build with --disable-shared ex13 runs ok in debug mode... but I do still get printing weirdness like this: ######### Mesh Information: mesh_dimension()= EquationSystems n_systems()= ######### Going to upgrade to 3.2.4 now.... Derek On Fri, Sep 17, 2010 at 8:22 AM, Derek Gaston <fri...@gm...> wrote: > Has anyone around here been able to successfully use libMesh with XCode > 3.2.3 on OSX? > > We've held off from upgrading to 3.2.3 for a while because of an > incompatibility with the Intel compilers.... but that incompatibility was > resolved so we have now tried 3.2.3... with epic failure. > > At this point I'm just using 3.2.3 with libMesh by itself. I'm not using > the Intel compiler... nor Petsc. I'm just letting it use all the default > stuff on OSX (including the built in MPI, etc). I'm not passing any options > to libmesh's configure. > > So if you want to reproduce this... just "upgrade" to XCode 3.2.3, checkout > libmesh do "./configure" and make in debug mode... then go build ex13 (just > chosen by random) in debug mode and you should see something like: > > ######### > Mesh Information: > mesh_dimension()= > EquationSystems > n_systems()= > ERROR: cannot convert system "Navier-Stokes" to requested type! > [0] /Users/gastdr/projects/libmesh/include/systems/equation_systems.h, line > 671, compiled Sep 17 2010 at 08:06:04 > terminate called after throwing an instance of 'libMesh::LogicError' > what(): Error in libMesh internal logic > [Derek-Gastons-MacBook-Pro:13048] *** Process received signal *** > [Derek-Gastons-MacBook-Pro:13048] Signal: Abort trap (6) > [Derek-Gastons-MacBook-Pro:13048] Signal code: (0) > [Derek-Gastons-MacBook-Pro:13048] [ 0] 2 libSystem.B.dylib > 0x00007fff803e735a _sigtramp + 26 > [Derek-Gastons-MacBook-Pro:13048] [ 1] 3 ??? > 0x00007fff5fbfde00 0x0 + 140734799797760 > [Derek-Gastons-MacBook-Pro:13048] [ 2] 4 libstdc++.6.dylib > 0x00007fff84f465d2 __tcf_0 + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 3] 5 libobjc.A.dylib > 0x00007fff819e4d3d _objc_terminate + 120 > [Derek-Gastons-MacBook-Pro:13048] [ 4] 6 libstdc++.6.dylib > 0x00007fff84f44ae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 > [Derek-Gastons-MacBook-Pro:13048] [ 5] 7 libstdc++.6.dylib > 0x00007fff84f44b16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 6] 8 libstdc++.6.dylib > 0x00007fff84f44bfc > _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 7] 9 ex13-dbg > 0x0000000100022d71 > _ZN7libMesh15EquationSystems10get_systemINS_15TransientSystemINS_20LinearImplicitSystemEEEEERT_RKSs > + 869 > [Derek-Gastons-MacBook-Pro:13048] [ 8] 10 ex13-dbg > 0x0000000100005c9d main + 1646 > [Derek-Gastons-MacBook-Pro:13048] [ 9] 11 ex13-dbg > 0x00000001000026dc start + 52 > ######### > > > After looking at the various problems for the past few days it appears to > be having trouble dynamic casting things... but I cannot see why. BUT... > that's not the only problem. Notice the weirdness where the "Mesh > Information" block didn't get printed completely. Some of the examples will > run just fine.. but exhibit weird behavior like incomplete printing of > information, etc. > > All in all... it's total weirdness... and I just want to make sure we're > not the only ones seeing it. > > I saw this morning that there is an XCode 3.2.4 out as of a week ago... so > I'm going to check that out today... but looking over the release notes I > don't see anything that would lead me to believe that this is fixed. I'll > report back. > > If 3.2.4 doesn't work I'm probably just going to have to downgrade to > 3.2.2. That's the situation we've been in for a while... but it is trouble > because we have to tell all of our customers with Macs NOT to upgrade to > 3.2.3 (which the OSX software update thing will happily tell them to do all > the time). So it would be nice if we could boil this down to something that > XCode is doing wrong so I can send it off to my Apple contacts so this can > get fixed once and for all. > > Derek > |
From: Ming Q <mi...@gm...> - 2010-09-17 14:36:01
|
Hi Derek, I saw the same problem of dynamic casting. I have to work around by using GNU compiler instead. / Ming Q. On Sep 17, 2010, at 4:22 PM, Derek Gaston wrote: > Has anyone around here been able to successfully use libMesh with XCode 3.2.3 on OSX? > > We've held off from upgrading to 3.2.3 for a while because of an incompatibility with the Intel compilers.... but that incompatibility was resolved so we have now tried 3.2.3... with epic failure. > > At this point I'm just using 3.2.3 with libMesh by itself. I'm not using the Intel compiler... nor Petsc. I'm just letting it use all the default stuff on OSX (including the built in MPI, etc). I'm not passing any options to libmesh's configure. > > So if you want to reproduce this... just "upgrade" to XCode 3.2.3, checkout libmesh do "./configure" and make in debug mode... then go build ex13 (just chosen by random) in debug mode and you should see something like: > > ######### > Mesh Information: > mesh_dimension()= > EquationSystems > n_systems()= > ERROR: cannot convert system "Navier-Stokes" to requested type! > [0] /Users/gastdr/projects/libmesh/include/systems/equation_systems.h, line 671, compiled Sep 17 2010 at 08:06:04 > terminate called after throwing an instance of 'libMesh::LogicError' > what(): Error in libMesh internal logic > [Derek-Gastons-MacBook-Pro:13048] *** Process received signal *** > [Derek-Gastons-MacBook-Pro:13048] Signal: Abort trap (6) > [Derek-Gastons-MacBook-Pro:13048] Signal code: (0) > [Derek-Gastons-MacBook-Pro:13048] [ 0] 2 libSystem.B.dylib 0x00007fff803e735a _sigtramp + 26 > [Derek-Gastons-MacBook-Pro:13048] [ 1] 3 ??? 0x00007fff5fbfde00 0x0 + 140734799797760 > [Derek-Gastons-MacBook-Pro:13048] [ 2] 4 libstdc++.6.dylib 0x00007fff84f465d2 __tcf_0 + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 3] 5 libobjc.A.dylib 0x00007fff819e4d3d _objc_terminate + 120 > [Derek-Gastons-MacBook-Pro:13048] [ 4] 6 libstdc++.6.dylib 0x00007fff84f44ae1 _ZN10__cxxabiv111__terminateEPFvvE + 11 > [Derek-Gastons-MacBook-Pro:13048] [ 5] 7 libstdc++.6.dylib 0x00007fff84f44b16 _ZN10__cxxabiv112__unexpectedEPFvvE + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 6] 8 libstdc++.6.dylib 0x00007fff84f44bfc _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception + 0 > [Derek-Gastons-MacBook-Pro:13048] [ 7] 9 ex13-dbg 0x0000000100022d71 _ZN7libMesh15EquationSystems10get_systemINS_15TransientSystemINS_20LinearImplicitSystemEEEEERT_RKSs + 869 > [Derek-Gastons-MacBook-Pro:13048] [ 8] 10 ex13-dbg 0x0000000100005c9d main + 1646 > [Derek-Gastons-MacBook-Pro:13048] [ 9] 11 ex13-dbg 0x00000001000026dc start + 52 > ######### > > > After looking at the various problems for the past few days it appears to be having trouble dynamic casting things... but I cannot see why. BUT... that's not the only problem. Notice the weirdness where the "Mesh Information" block didn't get printed completely. Some of the examples will run just fine.. but exhibit weird behavior like incomplete printing of information, etc. > > All in all... it's total weirdness... and I just want to make sure we're not the only ones seeing it. > > I saw this morning that there is an XCode 3.2.4 out as of a week ago... so I'm going to check that out today... but looking over the release notes I don't see anything that would lead me to believe that this is fixed. I'll report back. > > If 3.2.4 doesn't work I'm probably just going to have to downgrade to 3.2.2. That's the situation we've been in for a while... but it is trouble because we have to tell all of our customers with Macs NOT to upgrade to 3.2.3 (which the OSX software update thing will happily tell them to do all the time). So it would be nice if we could boil this down to something that XCode is doing wrong so I can send it off to my Apple contacts so this can get fixed once and for all. > > Derek > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2010-09-17 14:59:00
|
On Fri, 17 Sep 2010, Ming Q wrote: > I saw the same problem of dynamic casting. I have to work around by using GNU compiler instead. One stupid question and one serious one, for everybody: Is there any place in XCode where they're turning on -fno-rtti by default, and if so can that be user-disabled? Should we go through the library and change the rest of our dynamic_cast operations to libmesh_cast_*? Those become unchecked static_casts in non-debugging modes, which might work around the XCode problem. We currently use and test dynamic casts even in opt mode in situations like EquationSystems::get_system(), because users might call that method and we want to catch their bugs... but there are lots of places where we only check for user bugs in debug/devel modes; this could be another. --- Roy |
From: John P. <pet...@cf...> - 2010-09-17 15:04:09
|
On Fri, Sep 17, 2010 at 9:58 AM, Roy Stogner <roy...@ic...> wrote: > > > On Fri, 17 Sep 2010, Ming Q wrote: > >> I saw the same problem of dynamic casting. I have to work around by using GNU compiler instead. > > One stupid question and one serious one, for everybody: > > Is there any place in XCode where they're turning on -fno-rtti by > default, and if so can that be user-disabled? > > Should we go through the library and change the rest of our > dynamic_cast operations to libmesh_cast_*? I don't think we should change all of them! There are cases in the numerics classes where the intent is to downcast to a more derived type, e.g. a PetscVector. You'd have to look at each case by hand, which sounds like a pain. -- John |
From: Cody P. <cod...@gm...> - 2010-09-17 15:09:38
|
I agree, don't change anything - I think I'll send these issues to our Apple reps to see if we can get some answers here. This is an important issue that should be resolved by the vendor. Cody On Sep 17, 2010, at 9:03 AM, John Peterson wrote: > On Fri, Sep 17, 2010 at 9:58 AM, Roy Stogner <roy...@ic...> wrote: >> >> >> On Fri, 17 Sep 2010, Ming Q wrote: >> >>> I saw the same problem of dynamic casting. I have to work around by using GNU compiler instead. >> >> One stupid question and one serious one, for everybody: >> >> Is there any place in XCode where they're turning on -fno-rtti by >> default, and if so can that be user-disabled? >> >> Should we go through the library and change the rest of our >> dynamic_cast operations to libmesh_cast_*? > > I don't think we should change all of them! There are cases in the > numerics classes where the intent is to downcast to a more derived > type, e.g. a PetscVector. You'd have to look at each case by hand, > which sounds like a pain. > > -- > John > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Roy S. <roy...@ic...> - 2010-09-17 15:14:40
|
On Fri, 17 Sep 2010, John Peterson wrote: > On Fri, Sep 17, 2010 at 9:58 AM, Roy Stogner <roy...@ic...> wrote: >> >> >> On Fri, 17 Sep 2010, Ming Q wrote: >> >>> I saw the same problem of dynamic casting. I have to work around by using GNU compiler instead. >> >> One stupid question and one serious one, for everybody: >> >> Is there any place in XCode where they're turning on -fno-rtti by >> default, and if so can that be user-disabled? >> >> Should we go through the library and change the rest of our >> dynamic_cast operations to libmesh_cast_*? > > I don't think we should change all of them! There are cases in the > numerics classes where the intent is to downcast to a more derived > type, e.g. a PetscVector. You'd have to look at each case by hand, > which sounds like a pain. The downcasts are some of the ones I'd already changed: casting a NumericVector-which-we-know-is-a-PetscVector into a PetscVector is exactly the sort of scenario where libmesh_cast_* is useful. And checking less than 50 cases by hand won't be any more of a pain than the namespacing was. The only downside is removing some more error checks from opt mode, but we already have a lot of checks that aren't active there. --- Roy |
From: Derek G. <fri...@gm...> - 2010-09-17 15:09:51
|
On Fri, Sep 17, 2010 at 9:03 AM, John Peterson < pet...@cf...> wrote: > I don't think we should change all of them! There are cases in the > numerics classes where the intent is to downcast to a more derived > type, e.g. a PetscVector. You'd have to look at each case by hand, > which sounds like a pain. "Fixing" libmesh shouldn't be our concern here. We HAVE to be able to reliably dynamic cast. If the compiler isn't going to give that to us that's a non-starter. This isn't just a "make it work on OSX" moment. We shouldn't have to change any valid code just because Apple has a bug in their compilers. Derek |
From: Roy S. <roy...@ic...> - 2010-09-17 15:15:58
|
On Fri, 17 Sep 2010, Derek Gaston wrote: > "Fixing" libmesh shouldn't be our concern here. We HAVE to be able > to reliably dynamic cast. If the compiler isn't going to give that > to us that's a non-starter. Okay - if this isn't a sufficient workaround for you then I won't bother changing it in the near future; the only other benefits would be very slightly shorter code and an infintesimally shorter opt mode execution. --- Roy |
From: Paul T. B. <ptb...@gm...> - 2010-09-17 15:14:44
|
On Fri, Sep 17, 2010 at 10:09 AM, Derek Gaston <fri...@gm...> wrote: > > We shouldn't have to change any valid code just because Apple has a bug in > their compilers. > For giggles, have you tried building newer versions of gcc to see if this problem is still there? |
From: Derek G. <fri...@gm...> - 2010-09-17 15:24:03
|
On Fri, Sep 17, 2010 at 9:14 AM, Paul T. Bauman <ptb...@gm...> wrote: > On Fri, Sep 17, 2010 at 10:09 AM, Derek Gaston <fri...@gm...> wrote: > >> >> We shouldn't have to change any valid code just because Apple has a bug in >> their compilers. >> > > For giggles, have you tried building newer versions of gcc to see if this > problem is still there? > Any hand built version of GCC (or precompiled GCC from places like the OSX HPC website) works fine... other than it being ridiculously slow (which, I believe is one of the reasons Apple is going with LLVM and Clang compilers in the first place). BTW... just one more data point... XCode 3.2.4 doesn't help. I think I'm going to drop back to 3.2.1 for now... and file a bug report with Apple. Derek |