From: Cody P. <cod...@gm...> - 2012-09-20 15:53:32
|
I'm putting this on the list in case anyone wants to chime in, but I'm hoping that Paul might have some thoughts suggestions. We (the MOOSE team) are looking for a path forward on which compilers we want to use on OS X 10.8. Our single biggest holdup is our need for FORTRAN support. Currently we are using the Apple supplied compilers (4.2.1 branch) but we are finding it increasingly difficult to continue on this Path. With the recent breakage of dynamic templated casts, and the lack of a ready to go Xcode integrated Fortran compiler on 10.8 we are at an impasse. As I demonstrated yesterday, we were able to build with GCC using "legacy" compatibility switches - yuck! Paths Forward: Clang - This would be nice, however I'm not really liking our FORTRAN options if we go this route. There's this "dragonEgg" thingy we might be able to use but it feels hackish and is labeled as experimental. GNU GCC: This is probably our best option. The question is, do we build it from source, download binaries, or get it through Fink/Mac Ports? There are various advantages/disadvantages to each of these. Paul, you've been using GNU GCC (as opposed to Apple GCC) for sometime now. I know you've answered this before but what are your thoughts challenges with this? Have you ever messed with the Fortran piece? Derek found this link this morning so we are about to try this guys suggestion now: http://stackoverflow.com/questions/12316780/how-to-compile-distributable-fortran-binaries-on-mac-os-x-mountain-lion hpc.sourceforge.net: We've been down this road in the past too. In the past this guy used to put out a really nice suite of pre-built compilers. We had some negative experiences when GCC 4.5 was released and abandoned ship. We might look at this again though. Thanks everyone in advance for your thoughts on this subject, Cody |
From: Roy S. <roy...@ic...> - 2012-09-20 16:02:27
|
Not sure if this an option you want, but it's probably worth mentioning: should we have configure test for when templated casts are broken across dynamic library boundaries, and then turn off LIBMESH_HAVE_RTTI whenever that's the case? Internal to the library we're fine falling back on the static_cast code paths, so this would at least be a big help to new users on new OS X versions. What do you guys need Fortran support for? PETSc third-party libraries? In-house code? --- Roy |
From: Paul T. B. <ptb...@gm...> - 2012-09-20 16:04:14
|
Reply to Cody coming... On Thu, Sep 20, 2012 at 11:02 AM, Roy Stogner <roy...@ic...>wrote: > PETSc third-party libraries? I'm sure they have other things in mind, but, for example, you can't get MUMPS without a Fortran compiler. |
From: Boyce G. <gri...@ci...> - 2012-09-20 16:11:28
|
On 9/20/12 11:53 AM, Cody Permann wrote: > GNU GCC: This is probably our best option. The question is, do we build > it from source, download binaries, or get it through Fink/Mac Ports? > There are various advantages/disadvantages to each of these. Paul, > you've been using GNU GCC (as opposed to Apple GCC) for sometime now. I > know you've answered this before but what are your thoughts challenges > with this? Have you ever messed with the Fortran piece? Derek found > this link this morning so we are about to try this guys suggestion now: > http://stackoverflow.com/questions/12316780/how-to-compile-distributable-fortran-binaries-on-mac-os-x-mountain-lion I've been using Fink gcc/g++/gfortran with libMesh on OS X without any major difficulties. As always, YMMV. Best, -- Boyce |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-20 16:15:38
|
Caveat I am my running mountain lion, but I've been using the gcc default chain in macports for several years now and have been quite happy. Macports are a pain to update - everyhing is built from source so that is a lot of repeated work if you are maintaining a fleet, but it has worked for me. It gets good, stable and recent versions of everything I want, not just gcc... -Ben On Sep 20, 2012, at 10:11 AM, "Boyce Griffith" <gri...@ci...> wrote: > > > On 9/20/12 11:53 AM, Cody Permann wrote: >> GNU GCC: This is probably our best option. The question is, do we build >> it from source, download binaries, or get it through Fink/Mac Ports? >> There are various advantages/disadvantages to each of these. Paul, >> you've been using GNU GCC (as opposed to Apple GCC) for sometime now. I >> know you've answered this before but what are your thoughts challenges >> with this? Have you ever messed with the Fortran piece? Derek found >> this link this morning so we are about to try this guys suggestion now: >> http://stackoverflow.com/questions/12316780/how-to-compile-distributable-fortran-binaries-on-mac-os-x-mountain-lion > > I've been using Fink gcc/g++/gfortran with libMesh on OS X without any > major difficulties. As always, YMMV. > > Best, > > -- Boyce > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-09-20 16:17:05
|
(should read i am not yet running mountain lion) On Sep 20, 2012, at 10:15 AM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > Caveat I am my running mountain lion, but I've been using the gcc default chain in macports for several years now and have been quite happy. > > Macports are a pain to update - everyhing is built from source so that is a lot of repeated work if you are maintaining a fleet, but it has worked for me. It gets good, stable and recent versions of everything I want, not just gcc... > > -Ben > > > > On Sep 20, 2012, at 10:11 AM, "Boyce Griffith" <gri...@ci...> wrote: > >> >> >> On 9/20/12 11:53 AM, Cody Permann wrote: >>> GNU GCC: This is probably our best option. The question is, do we build >>> it from source, download binaries, or get it through Fink/Mac Ports? >>> There are various advantages/disadvantages to each of these. Paul, >>> you've been using GNU GCC (as opposed to Apple GCC) for sometime now. I >>> know you've answered this before but what are your thoughts challenges >>> with this? Have you ever messed with the Fortran piece? Derek found >>> this link this morning so we are about to try this guys suggestion now: >>> http://stackoverflow.com/questions/12316780/how-to-compile-distributable-fortran-binaries-on-mac-os-x-mountain-lion >> >> I've been using Fink gcc/g++/gfortran with libMesh on OS X without any >> major difficulties. As always, YMMV. >> >> Best, >> >> -- Boyce >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Libmesh-devel mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Cody P. <cod...@gm...> - 2012-09-20 16:19:55
|
On Thu, Sep 20, 2012 at 10:02 AM, Roy Stogner <roy...@ic...>wrote: > > Not sure if this an option you want, but it's probably worth > mentioning: should we have configure test for when templated casts are > broken across dynamic library boundaries, and then turn off > LIBMESH_HAVE_RTTI whenever that's the case? Well from a library perspective, this might be the right thing to do, but it makes me wonder what the future of this particular compiler will be on OS X. It feels like Apple is going to eventually stop supporting it and move to Clang/LLVM exclusively. If that's the case, perhaps we could just add the -mmacosx-version-min=10.5 flag to the existing compiler which seems to rectify the problem on newer versions of XCode. I could figure out which versions and adjust compiler.m4 appropriately. No need to adjust libMesh to handle yet another broken compiler. > Internal to the library > we're fine falling back on the static_cast code paths, so this would > at least be a big help to new users on new OS X versions. > > What do you guys need Fortran support for? PETSc third-party > libraries? In-house code? > We need Fortran to support various legacy subroutines. We allow our users to re-use existing Fortran for things like material property calculations in MOOSE. It helps ease the transition to C++ that many of our engineering friends have to go through in using the framework. MOOSE itself doesn't have any Fortran in it, but our end applications... That's another story Cody > --- > Roy > |
From: Roy S. <roy...@ic...> - 2012-09-20 16:27:19
|
On Thu, 20 Sep 2012, Cody Permann wrote: > It feels like Apple is going to eventually stop supporting it and > move to Clang/LLVM exclusively. If that's the case, perhaps we > could just add the -mmacosx-version-min=10.5 flag to the existing > compiler which seems to rectify the problem on newer versions of > XCode. I could figure out which versions and adjust > compiler.m4 appropriately. No need to adjust libMesh to handle yet > another broken compiler. I'd appreciate that, thanks. I haven't *quite* broken down and gotten a Mac laptop, so I'm unable to test any changes, and my only personal stake here is that I don't want the mailing lists to start filling up with "why are you broken?" hatemail that ought to be directed toward Apple instead. :-) --- Roy |
From: Paul T. B. <ptb...@gm...> - 2012-09-20 16:26:04
|
On Thu, Sep 20, 2012 at 10:53 AM, Cody Permann <cod...@gm...>wrote: > Our single biggest holdup is our need for FORTRAN support. > Ditto. This is why I started worrying about this almost 10 years ago. Paths Forward: > Clang - This would be nice, however I'm not really liking our FORTRAN > options if we go this route. There's this "dragonEgg" thingy we might be > able to use but it feels hackish and is labeled as experimental. > I'm still dubious of Clang, but maybe it's more mature now than I think is (when Lion was released, Macports was a mess for a couple of months because Clang was generating wrong code). That said, I haven't tried this yet. > > GNU GCC: This is probably our best option. The question is, do we build > it from source, download binaries, or get it through Fink/Mac Ports? There > are various advantages/disadvantages to each of these. Paul, you've been > using GNU GCC (as opposed to Apple GCC) for sometime now. I know you've > answered this before but what are your thoughts challenges with this? Have > you ever messed with the Fortran piece? > First, G95 is horrible. I had a lot of problems with it. gfortran has been an excellent Fortran 77/90 compiler since 4.4. And is very close to fully functional 2003 as of 4.7. I tried Fink a long time ago and ultimately abandoned it because it was hard to uninstall things and it liked to put stuff in places like /usr which annoyed me very much. It's been a long time since I've used it (6 years I think), so it very well could have changed. I use MacPorts for everything *but* the compilers/compiled libraries I use. In particular, I MacPorts to supply autotools, octave, doxygen, coreutils (GNU instead of BSD utilities), python and all python modules (e.g. numpy, matplotlib), scons, etc. This works very very well for me. The only caveat, as mentioned above, when the OS changes, Apple tends to pull the rug out from under you on the compiler and it can take come time for MacPorts to catch up. Some folks around here also use MacPorts for supplying the compiler, MPI stack, HDF5, and some others. If you're *very* careful, this can work. The problem is that it's *really* easy to have the compiler you're using and the compiler used to compile a library not match up. For example, the maintainer of the boost port might decide to switch to a different compiler port and it's practically invisible to you. Folks had/have a lot of linking trouble because of this. I have not tried using just the MacPorts compiler and building my own stuff, but, again, you can run into linker problems because, for example, if you use boost, depending on where /opt/local/lib gets pulled in on the linker line (for the compiler libraries), you could end up pulling in boost from macports. So, if you leverage MacPorts for a lot of stuff, this can easily happen. If you keep your MacPorts install lean, you'll probably be able to avoid these issues. Given the above discussion, I've been building from scratch for a long time. Another perk is you can try out new compilers early on and anticipate problems that might crop up. Building from scratch is, really, very simple and can be handled completely with script(s). You will need GMP, MPFR (and MPC for gcc >= 4.5), which I also tend to build. This has worked very well for me. However, as of OS X Lion, there have been a couple of problems that I haven't been able to figure out and that have persisted into Mountain Lion which you will want to consider. libMesh miscellaneous_ex6 outright fails with an ugly stack trace that goes all the way to a linker function. I have also not been able to get TBB to work with libMesh successfully (segfaults) on my laptop (works fine on Linux workstation). However, every other code I compile and use has run just fine, in parallel, etc including Fortran codes. However, I'm still nervous because I haven't been able to sort out the above couple of issues. > > hpc.sourceforge.net: We've been down this road in the past too. In the > past this guy used to put out a really nice suite of pre-built compilers. > We had some negative experiences when GCC 4.5 was released > and abandoned ship. We might look at this again though. > I've never tried this. > Thanks everyone in advance for your thoughts on this subject, > Let me know if you have any other questions, I'll be happy to give whatever experience/scripts/etc I have. Best, Paul |
From: Paul T. B. <ptb...@gm...> - 2012-09-20 16:34:05
|
On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann <cod...@gm...>wrote: > If that's the case, perhaps we could just add > the -mmacosx-version-min=10.5 flag to the existing compiler which seems to > rectify the problem on newer versions of XCode. I could figure out which > versions and adjust compiler.m4 appropriately. > Just to log here since I was on a private thread with Cody: my build-from-source compiler (gcc 4.6) didn't seem to have the dynamic_cast issue, but the addition of the flag did not seem to affect my builds in any visible way. So, I'm good with this route (as a Mac user). Thanks, Paul |
From: Cody P. <cod...@gm...> - 2012-09-20 16:37:07
|
On Thu, Sep 20, 2012 at 10:33 AM, Paul T. Bauman <ptb...@gm...> wrote: > On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann <cod...@gm...>wrote: > >> If that's the case, perhaps we could just add >> the -mmacosx-version-min=10.5 flag to the existing compiler which seems to >> rectify the problem on newer versions of XCode. I could figure out which >> versions and adjust compiler.m4 appropriately. >> > > Just to log here since I was on a private thread with Cody: my > build-from-source compiler (gcc 4.6) didn't seem to have the dynamic_cast > issue, but the addition of the flag did not seem to affect my builds in any > visible way. So, I'm good with this route (as a Mac user). > > If I do add this flag, I intend to enable it ONLY for the Mac supplied compilers (4.2.1) on the appropriate versions of XCode. I don't see any reason to pollute any other GCC compilers with this nastiness. Cody > Thanks, > > Paul > > |
From: Cody P. <cod...@gm...> - 2012-09-24 17:38:11
|
On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman <ptb...@gm...> wrote: > On Thu, Sep 20, 2012 at 10:53 AM, Cody Permann <cod...@gm...>wrote: > >> Our single biggest holdup is our need for FORTRAN support. >> > > Ditto. This is why I started worrying about this almost 10 years ago. > > Paths Forward: >> Clang - This would be nice, however I'm not really liking our FORTRAN >> options if we go this route. There's this "dragonEgg" thingy we might be >> able to use but it feels hackish and is labeled as experimental. >> > > I'm still dubious of Clang, but maybe it's more mature now than I think is > (when Lion was released, Macports was a mess for a couple of months because > Clang was generating wrong code). That said, I haven't tried this yet. > > >> >> GNU GCC: This is probably our best option. The question is, do we build >> it from source, download binaries, or get it through Fink/Mac Ports? There >> are various advantages/disadvantages to each of these. Paul, you've been >> using GNU GCC (as opposed to Apple GCC) for sometime now. I know you've >> answered this before but what are your thoughts challenges with this? Have >> you ever messed with the Fortran piece? >> > > First, G95 is horrible. I had a lot of problems with it. gfortran has been > an excellent Fortran 77/90 compiler since 4.4. And is very close to fully > functional 2003 as of 4.7. > > I tried Fink a long time ago and ultimately abandoned it because it was > hard to uninstall things and it liked to put stuff in places like /usr > which annoyed me very much. It's been a long time since I've used it (6 > years I think), so it very well could have changed. > > I use MacPorts for everything *but* the compilers/compiled libraries I > use. In particular, I MacPorts to supply autotools, octave, doxygen, > coreutils (GNU instead of BSD utilities), python and all python modules > (e.g. numpy, matplotlib), scons, etc. This works very very well for me. The > only caveat, as mentioned above, when the OS changes, Apple tends to pull > the rug out from under you on the compiler and it can take come time for > MacPorts to catch up. > > Some folks around here also use MacPorts for supplying the compiler, MPI > stack, HDF5, and some others. If you're *very* careful, this can work. The > problem is that it's *really* easy to have the compiler you're using and > the compiler used to compile a library not match up. For example, the > maintainer of the boost port might decide to switch to a different compiler > port and it's practically invisible to you. Folks had/have a lot of linking > trouble because of this. I have not tried using just the MacPorts compiler > and building my own stuff, but, again, you can run into linker problems > because, for example, if you use boost, depending on where /opt/local/lib > gets pulled in on the linker line (for the compiler libraries), you could > end up pulling in boost from macports. So, if you leverage MacPorts for a > lot of stuff, this can easily happen. If you keep your MacPorts install > lean, you'll probably be able to avoid these issues. > > Given the above discussion, I've been building from scratch for a long > time. Another perk is you can try out new compilers early on and anticipate > problems that might crop up. Building from scratch is, really, very simple > and can be handled completely with script(s). You will need GMP, MPFR (and > MPC for gcc >= 4.5), which I also tend to build. This has worked very well > for me. However, as of OS X Lion, there have been a couple of problems that > I haven't been able to figure out and that have persisted into Mountain > Lion which you will want to consider. libMesh miscellaneous_ex6 outright > fails with an ugly stack trace that goes all the way to a linker function. > I have also not been able to get TBB to work with libMesh successfully > (segfaults) on my laptop (works fine on Linux workstation). However, every > other code I compile and use has run just fine, in parallel, etc including > Fortran codes. However, I'm still nervous because I haven't been able to > sort out the above couple of issues. > > Paul, Would you be will to share your build scripts with us for building GCC from source? I think we are ready to try this route next. I really would like to get MOOSE and a few of our applications that use FORTRAN running on Mountain Lion this week if possible. It seems that building from source may be our next best option at this point. Thanks, Cody > >> hpc.sourceforge.net: We've been down this road in the past too. In the >> past this guy used to put out a really nice suite of pre-built compilers. >> We had some negative experiences when GCC 4.5 was released >> and abandoned ship. We might look at this again though. >> > > I've never tried this. > > >> Thanks everyone in advance for your thoughts on this subject, >> > > Let me know if you have any other questions, I'll be happy to give > whatever experience/scripts/etc I have. > > Best, > > Paul > > |
From: Paul T. B. <ptb...@gm...> - 2012-09-26 14:24:11
|
On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman <ptb...@gm...> wrote: > libMesh miscellaneous_ex6 outright fails with an ugly stack trace that >> goes all the way to a linker function. I have also not been able to get TBB >> to work with libMesh successfully (segfaults) on my laptop (works fine on >> Linux workstation). However, every other code I compile and use has run >> just fine, in parallel, etc including Fortran codes. However, I'm still >> nervous because I haven't been able to sort out the above couple of issues. >> > Thought I'd follow up here. I've been working in libMesh trunk for awhile, so I hadn't tried out the branch on my laptop for some time. I did last night and these issues go away there (but they are still there in trunk). In particular, all examples run correctly and I can run everything (including my applications) with TBB on my Mac using built compilers etc. I don't have time to dig right now for what the difference is, but I thought I'd at least pass this along. (If I had to guess, the difference is either 1. libtool is stripping out some link flags that were causing the problem or 2. libtool is doing something different in how it links together the contributed libraries with the libMesh sources or 3. Something else). FWIW, Paul |
From: Cody P. <cod...@gm...> - 2012-09-26 14:30:34
|
On Wed, Sep 26, 2012 at 8:24 AM, Paul T. Bauman <ptb...@gm...> wrote: > On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman <ptb...@gm...>wrote: > >> libMesh miscellaneous_ex6 outright fails with an ugly stack trace that >>> goes all the way to a linker function. I have also not been able to get TBB >>> to work with libMesh successfully (segfaults) on my laptop (works fine on >>> Linux workstation). However, every other code I compile and use has run >>> just fine, in parallel, etc including Fortran codes. However, I'm still >>> nervous because I haven't been able to sort out the above couple of issues. >>> >> > Thought I'd follow up here. I've been working in libMesh trunk for awhile, > so I hadn't tried out the branch on my laptop for some time. I did last > night and these issues go away there (but they are still there in trunk). > In particular, all examples run correctly and I can run everything > (including my applications) with TBB on my Mac using built compilers etc. I > don't have time to dig right now for what the difference is, but I thought > I'd at least pass this along. (If I had to guess, the difference is either > 1. libtool is stripping out some link flags that were causing the problem > or 2. libtool is doing something different in how it links together the > contributed libraries with the libMesh sources or 3. Something else). > > FWIW, > > Interesting, I was just thinking about digging back through my mail to find this issue since we just got the stack going this morning. It looks like the majority of our applications are running just fine with our GCC stack (w/ gfortran) on Mountain Lion! We also built Clang from source and it's also working with gfortran as well so we are fairly pleased with these results. We have only one issue right now but it should be fairly easy to sort out. It has to do with our "plugin" system which does dynamic library loading but other than that, everything else is working just fine. I'll let you know if we run into that issue or if we see anything odd. Thanks again for the scripts, they were very useful in getting us up and running, Cody > Paul > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-03 13:35:19
|
>> Thought I'd follow up here. I've been working in libMesh trunk for awhile, so >> I hadn't tried out the branch on my laptop for some time. I did last night >> and >> these issues go away there (but they are still there in trunk). In >> particular, >> all examples run correctly and I can run everything (including my >> applications) with TBB on my Mac using built compilers etc. I don't have time >> to dig right now for what the difference is, but I thought I'd at least pass >> this along. (If I had to guess, the difference is either 1. libtool is >> stripping out some link flags that were causing the problem or 2. libtool is >> doing something different in how it links together the contributed libraries >> with the libMesh sources or 3. Something else). > > Interesting, I was just thinking about digging back through my mail to find > this issue since we just got the stack going this morning. It looks like the > majority of our applications are running just fine with our GCC stack (w/ > gfortran) on Mountain Lion! We also built Clang from source and it's also > working with gfortran as well so we are fairly pleased with these results. We > have only one issue right now but it should be fairly easy to sort out. It > has to do with our "plugin" system which does dynamic library loading but > other than that, everything else is working just fine. I'll let you know if > we run into that issue or if we see anything odd. So I'm now the proud owner of a mountain lion retina display, and spent most of yesterday setting up the machine. I have been able to install everything from MacPorts, including petsc/slepc, and run the libmesh.automake branch just fine. As for the above comment - was that Paul saying there are problems with trunk but not the branch? Or is everyone happy now with both branch and trunk on Mountain Lion? I'm planning to merge the automake branch after the PECOS review later this month. -Ben |
From: Cody P. <cod...@gm...> - 2012-10-20 14:30:49
|
On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > >> Thought I'd follow up here. I've been working in libMesh trunk for > awhile, so > >> I hadn't tried out the branch on my laptop for some time. I did last > night > >> and > >> these issues go away there (but they are still there in trunk). In > >> particular, > >> all examples run correctly and I can run everything (including my > >> applications) with TBB on my Mac using built compilers etc. I don't > have time > >> to dig right now for what the difference is, but I thought I'd at least > pass > >> this along. (If I had to guess, the difference is either 1. libtool is > >> stripping out some link flags that were causing the problem or 2. > libtool is > >> doing something different in how it links together the contributed > libraries > >> with the libMesh sources or 3. Something else). > > > > Interesting, I was just thinking about digging back through my mail to > find > > this issue since we just got the stack going this morning. It looks > like the > > majority of our applications are running just fine with our GCC stack (w/ > > gfortran) on Mountain Lion! We also built Clang from source and it's > also > > working with gfortran as well so we are fairly pleased with these > results. We > > have only one issue right now but it should be fairly easy to sort out. > It > > has to do with our "plugin" system which does dynamic library loading but > > other than that, everything else is working just fine. I'll let you > know if > > we run into that issue or if we see anything odd. > > So I'm now the proud owner of a mountain lion retina display, and spent > most > of yesterday setting up the machine. I have been able to install > everything > from MacPorts, including petsc/slepc, and run the libmesh.automake branch > just fine. > > Ben, I just received my new Macbook Pro too and have similarly had a pleasant experience with the ease of installing everything I need through MacPorts. I do have one serious issue which is still plaguing me though. I've been chatting a bit with Paul off list but still haven't gotten to the bottom of the problem yet. Up 'til now, all of us at the INL have been using the Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be quite the shift for us. The thing is, that I've yet to successfully build libMesh in debug mode using GCC on any ML box. We've tried numerous times building the compilers from source, using MacPorts, and downloading them for hpc.sourceforge.net. I keep thinking that we are doing something wrong since I'm not seeing any chatter on this list about other devs having issues. I believe that there are some real bugs in fparser that are really hosing things up. With are hacks to the Makefile and our object extensions it's sometimes possible to build in debug mode if you've built in optimized mode first! So my question is, have you seen this issue? Can you configure libMesh with fparser support and build in debug mode first (before you build optimized mode) without issues? I'm able to replicate the problem on both trunk and the automake branch and I now have the exact same configuration as you do. Oh and Paul, if you are following along, note that I said that I'm seeing the same problem in the automake branch now. When Jason ran the test the other day, I told you it was working but it appears that is not the case. I've tried numerous times and can always make it fail if the branch is clean. We have a few issues with make clean at the root level which do not clean up the fparser directory correctly. Nothing "git clean" can't fix though ;) Let me know if you have any insights, Thanks, Cody > As for the above comment - was that Paul saying there are problems with > trunk but not the branch? Or is everyone happy now with both branch and > trunk on Mountain Lion? > > I'm planning to merge the automake branch after the PECOS review later this > month. > > -Ben > > > > > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-20 14:56:49
|
I'll double check with the latest port of everything, although I do think a lot of this is self imposed - why don't we use the released fparser package? The development version uses yacc and makes a *lot* of assumptions about the compiler! -Ben On Oct 20, 2012, at 9:30 AM, "Cody Permann" <cod...@gm...<mailto:cod...@gm...>> wrote: On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: >> Thought I'd follow up here. I've been working in libMesh trunk for awhile, so >> I hadn't tried out the branch on my laptop for some time. I did last night >> and >> these issues go away there (but they are still there in trunk). In >> particular, >> all examples run correctly and I can run everything (including my >> applications) with TBB on my Mac using built compilers etc. I don't have time >> to dig right now for what the difference is, but I thought I'd at least pass >> this along. (If I had to guess, the difference is either 1. libtool is >> stripping out some link flags that were causing the problem or 2. libtool is >> doing something different in how it links together the contributed libraries >> with the libMesh sources or 3. Something else). > > Interesting, I was just thinking about digging back through my mail to find > this issue since we just got the stack going this morning. It looks like the > majority of our applications are running just fine with our GCC stack (w/ > gfortran) on Mountain Lion! We also built Clang from source and it's also > working with gfortran as well so we are fairly pleased with these results. We > have only one issue right now but it should be fairly easy to sort out. It > has to do with our "plugin" system which does dynamic library loading but > other than that, everything else is working just fine. I'll let you know if > we run into that issue or if we see anything odd. So I'm now the proud owner of a mountain lion retina display, and spent most of yesterday setting up the machine. I have been able to install everything from MacPorts, including petsc/slepc, and run the libmesh.automake branch just fine. Ben, I just received my new Macbook Pro too and have similarly had a pleasant experience with the ease of installing everything I need through MacPorts. I do have one serious issue which is still plaguing me though. I've been chatting a bit with Paul off list but still haven't gotten to the bottom of the problem yet. Up 'til now, all of us at the INL have been using the Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be quite the shift for us. The thing is, that I've yet to successfully build libMesh in debug mode using GCC on any ML box. We've tried numerous times building the compilers from source, using MacPorts, and downloading them for hpc.sourceforge.net<http://hpc.sourceforge.net>. I keep thinking that we are doing something wrong since I'm not seeing any chatter on this list about other devs having issues. I believe that there are some real bugs in fparser that are really hosing things up. With are hacks to the Makefile and our object extensions it's sometimes possible to build in debug mode if you've built in optimized mode first! So my question is, have you seen this issue? Can you configure libMesh with fparser support and build in debug mode first (before you build optimized mode) without issues? I'm able to replicate the problem on both trunk and the automake branch and I now have the exact same configuration as you do. Oh and Paul, if you are following along, note that I said that I'm seeing the same problem in the automake branch now. When Jason ran the test the other day, I told you it was working but it appears that is not the case. I've tried numerous times and can always make it fail if the branch is clean. We have a few issues with make clean at the root level which do not clean up the fparser directory correctly. Nothing "git clean" can't fix though ;) Let me know if you have any insights, Thanks, Cody As for the above comment - was that Paul saying there are problems with trunk but not the branch? Or is everyone happy now with both branch and trunk on Mountain Lion? I'm planning to merge the automake branch after the PECOS review later this month. -Ben |
From: Cody P. <cod...@gm...> - 2012-10-20 14:59:26
|
On Sat, Oct 20, 2012 at 8:56 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > I'll double check with the latest port of everything, although I do think > a lot of this is self imposed - why don't we use the released fparser > package? > I completely agree! We used the release version in MOOSE for a long time before there was interest in including it in libMesh. If for no other reason than to cut 15 seconds off the build time! :-) > > The development version uses yacc and makes a *lot* of assumptions about > the compiler! > > -Ben > > > > On Oct 20, 2012, at 9:30 AM, "Cody Permann" <cod...@gm...> wrote: > > > > On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) < > ben...@na...> wrote: > >> >> Thought I'd follow up here. I've been working in libMesh trunk for >> awhile, so >> >> I hadn't tried out the branch on my laptop for some time. I did last >> night >> >> and >> >> these issues go away there (but they are still there in trunk). In >> >> particular, >> >> all examples run correctly and I can run everything (including my >> >> applications) with TBB on my Mac using built compilers etc. I don't >> have time >> >> to dig right now for what the difference is, but I thought I'd at >> least pass >> >> this along. (If I had to guess, the difference is either 1. libtool is >> >> stripping out some link flags that were causing the problem or 2. >> libtool is >> >> doing something different in how it links together the contributed >> libraries >> >> with the libMesh sources or 3. Something else). >> > >> > Interesting, I was just thinking about digging back through my mail to >> find >> > this issue since we just got the stack going this morning. It looks >> like the >> > majority of our applications are running just fine with our GCC stack >> (w/ >> > gfortran) on Mountain Lion! We also built Clang from source and it's >> also >> > working with gfortran as well so we are fairly pleased with these >> results. We >> > have only one issue right now but it should be fairly easy to sort out. >> It >> > has to do with our "plugin" system which does dynamic library loading >> but >> > other than that, everything else is working just fine. I'll let you >> know if >> > we run into that issue or if we see anything odd. >> >> So I'm now the proud owner of a mountain lion retina display, and spent >> most >> of yesterday setting up the machine. I have been able to install >> everything >> from MacPorts, including petsc/slepc, and run the libmesh.automake branch >> just fine. >> >> > Ben, > > I just received my new Macbook Pro too and have similarly had a pleasant > experience with the ease of installing everything I need through MacPorts. > I do have one serious issue which is still plaguing me though. I've been > chatting a bit with Paul off list but still haven't gotten to the bottom of > the problem yet. Up 'til now, all of us at the INL have been using the > Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be > quite the shift for us. The thing is, that I've yet to successfully build > libMesh in debug mode using GCC on any ML box. We've tried numerous times > building the compilers from source, using MacPorts, and downloading them > for hpc.sourceforge.net. I keep thinking that we are doing something > wrong since I'm not seeing any chatter on this list about other devs having > issues. I believe that there are some real bugs in fparser that are really > hosing things up. With are hacks to the Makefile and our > object extensions it's sometimes possible to build in debug mode if you've > built in optimized mode first! > > So my question is, have you seen this issue? Can you configure libMesh > with fparser support and build in debug mode first (before you build > optimized mode) without issues? I'm able to replicate the problem on both > trunk and the automake branch and I now have the exact same configuration > as you do. > > Oh and Paul, if you are following along, note that I said that I'm seeing > the same problem in the automake branch now. When Jason ran the test the > other day, I told you it was working but it appears that is not the case. > I've tried numerous times and can always make it fail if the branch is > clean. We have a few issues with make clean at the root level which do not > clean up the fparser directory correctly. Nothing "git clean" can't fix > though ;) > > Let me know if you have any insights, > Thanks, > Cody > > >> As for the above comment - was that Paul saying there are problems with >> trunk but not the branch? Or is everyone happy now with both branch and >> trunk on Mountain Lion? >> >> I'm planning to merge the automake branch after the PECOS review later >> this >> month. >> >> -Ben >> >> >> >> >> > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-20 15:56:30
|
>> >> I'll double check with the latest port of everything, although I do think a lot of this is self imposed - why don't we use the released fparser package? >> >> The development version uses yacc and makes a *lot* of assumptions about the compiler! > I completely agree! We used the release version in MOOSE for a long time before there was interest in including it in libMesh. If for no other reason than to cut 15 seconds off the build time! :-) I'll let Roy weigh in, but my observation has been that 90% of the current build requirements are to make the source compressor/obfuscator that in the end produces a single source file… and a lot of the compiler issues I've seen are with actually the compressor, not fparser itself. Glad to hear you are not opposed to this option! -Ben |
From: Cody P. <cod...@gm...> - 2012-10-22 13:47:02
|
On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > >> > >> I'll double check with the latest port of everything, although I do > think a lot of this is self imposed - why don't we use the released fparser > package? > >> > >> The development version uses yacc and makes a *lot* of assumptions > about the compiler! > > > I completely agree! We used the release version in MOOSE for a long > time before there was interest in including it in libMesh. If for no other > reason than to cut 15 seconds off the build time! :-) > > I'll let Roy weigh in, but my observation has been that 90% of the current > build requirements are to make the source compressor/obfuscator that in the > end produces a single source file… and a lot of the compiler issues I've > seen are with actually the compressor, not fparser itself. > Roy, any thoughts on this or are we crazy here at the INL? I'm willing to prepare a patch to go back to the release version of the package or perhaps we could do something in between. Maybe "--enable-fparser-devel" and have it default to disabled bringing in only the release files for normal builds. Cody > > Glad to hear you are not opposed to this option! > > -Ben > > |
From: Roy S. <roy...@ic...> - 2012-10-22 14:51:14
|
On Mon, 22 Oct 2012, Cody Permann wrote: > > On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > > > I'll let Roy weigh in, but my observation has been that 90% of the > > current build requirements are to make the source > > compressor/obfuscator that in the end produces a single source > > file… and a lot of the compiler issues I've seen are with actually > > the compressor, not fparser itself. > > Roy, any thoughts on this or are we crazy here at the INL? I'm > willing to prepare a patch to go back to the release version of the > package or perhaps we could do something in between. Maybe > "--enable-fparser-devel" and have it default to disabled bringing in > only the release files for > normal builds. IIRC when I added fparser what I grabbed was the release version at the time (4.3?) - I've certainly got no need for any newer features myself, and based on the amount of futzing I had to do to get it to build properly with our system I'd need some significant incentives before I'd want to spend time tracking a non-release version. My vote for "something in between" would just be the 4.5 release itself, unless there's any known bugs that have been fixed in the devel snapshots but not wrapped up in a stable release yet. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-22 13:53:01
|
Cody, back to the subject though - Yeah, on the automake branch with macports gcc4.5 everyhing is ok, even in debug mode. What happens when you run ./bootstrap ./contrib/bin/buildall.sh? -Ben On Oct 20, 2012, at 9:30 AM, "Cody Permann" <cod...@gm...<mailto:cod...@gm...>> wrote: On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: >> Thought I'd follow up here. I've been working in libMesh trunk for awhile, so >> I hadn't tried out the branch on my laptop for some time. I did last night >> and >> these issues go away there (but they are still there in trunk). In >> particular, >> all examples run correctly and I can run everything (including my >> applications) with TBB on my Mac using built compilers etc. I don't have time >> to dig right now for what the difference is, but I thought I'd at least pass >> this along. (If I had to guess, the difference is either 1. libtool is >> stripping out some link flags that were causing the problem or 2. libtool is >> doing something different in how it links together the contributed libraries >> with the libMesh sources or 3. Something else). > > Interesting, I was just thinking about digging back through my mail to find > this issue since we just got the stack going this morning. It looks like the > majority of our applications are running just fine with our GCC stack (w/ > gfortran) on Mountain Lion! We also built Clang from source and it's also > working with gfortran as well so we are fairly pleased with these results. We > have only one issue right now but it should be fairly easy to sort out. It > has to do with our "plugin" system which does dynamic library loading but > other than that, everything else is working just fine. I'll let you know if > we run into that issue or if we see anything odd. So I'm now the proud owner of a mountain lion retina display, and spent most of yesterday setting up the machine. I have been able to install everything from MacPorts, including petsc/slepc, and run the libmesh.automake branch just fine. Ben, I just received my new Macbook Pro too and have similarly had a pleasant experience with the ease of installing everything I need through MacPorts. I do have one serious issue which is still plaguing me though. I've been chatting a bit with Paul off list but still haven't gotten to the bottom of the problem yet. Up 'til now, all of us at the INL have been using the Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be quite the shift for us. The thing is, that I've yet to successfully build libMesh in debug mode using GCC on any ML box. We've tried numerous times building the compilers from source, using MacPorts, and downloading them for hpc.sourceforge.net<http://hpc.sourceforge.net>. I keep thinking that we are doing something wrong since I'm not seeing any chatter on this list about other devs having issues. I believe that there are some real bugs in fparser that are really hosing things up. With are hacks to the Makefile and our object extensions it's sometimes possible to build in debug mode if you've built in optimized mode first! So my question is, have you seen this issue? Can you configure libMesh with fparser support and build in debug mode first (before you build optimized mode) without issues? I'm able to replicate the problem on both trunk and the automake branch and I now have the exact same configuration as you do. Oh and Paul, if you are following along, note that I said that I'm seeing the same problem in the automake branch now. When Jason ran the test the other day, I told you it was working but it appears that is not the case. I've tried numerous times and can always make it fail if the branch is clean. We have a few issues with make clean at the root level which do not clean up the fparser directory correctly. Nothing "git clean" can't fix though ;) Let me know if you have any insights, Thanks, Cody As for the above comment - was that Paul saying there are problems with trunk but not the branch? Or is everyone happy now with both branch and trunk on Mountain Lion? I'm planning to merge the automake branch after the PECOS review later this month. -Ben |
From: Cody P. <cod...@gm...> - 2012-10-22 14:04:29
|
On Mon, Oct 22, 2012 at 7:52 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Cody, back to the subject though - > > Yeah, on the automake branch with macports gcc4.5 everyhing is ok, even in > debug mode. > > I've tried with gcc4.6 and 4.7. I'll give 4.5 a shot. > What happens when you run > > ./bootstrap > ./contrib/bin/buildall.sh? > Let me try it now and I"ll let you know. Cody > > -Ben > > > > On Oct 20, 2012, at 9:30 AM, "Cody Permann" <cod...@gm...> wrote: > > > > On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) < > ben...@na...> wrote: > >> >> Thought I'd follow up here. I've been working in libMesh trunk for >> awhile, so >> >> I hadn't tried out the branch on my laptop for some time. I did last >> night >> >> and >> >> these issues go away there (but they are still there in trunk). In >> >> particular, >> >> all examples run correctly and I can run everything (including my >> >> applications) with TBB on my Mac using built compilers etc. I don't >> have time >> >> to dig right now for what the difference is, but I thought I'd at >> least pass >> >> this along. (If I had to guess, the difference is either 1. libtool is >> >> stripping out some link flags that were causing the problem or 2. >> libtool is >> >> doing something different in how it links together the contributed >> libraries >> >> with the libMesh sources or 3. Something else). >> > >> > Interesting, I was just thinking about digging back through my mail to >> find >> > this issue since we just got the stack going this morning. It looks >> like the >> > majority of our applications are running just fine with our GCC stack >> (w/ >> > gfortran) on Mountain Lion! We also built Clang from source and it's >> also >> > working with gfortran as well so we are fairly pleased with these >> results. We >> > have only one issue right now but it should be fairly easy to sort out. >> It >> > has to do with our "plugin" system which does dynamic library loading >> but >> > other than that, everything else is working just fine. I'll let you >> know if >> > we run into that issue or if we see anything odd. >> >> So I'm now the proud owner of a mountain lion retina display, and spent >> most >> of yesterday setting up the machine. I have been able to install >> everything >> from MacPorts, including petsc/slepc, and run the libmesh.automake branch >> just fine. >> >> > Ben, > > I just received my new Macbook Pro too and have similarly had a pleasant > experience with the ease of installing everything I need through MacPorts. > I do have one serious issue which is still plaguing me though. I've been > chatting a bit with Paul off list but still haven't gotten to the bottom of > the problem yet. Up 'til now, all of us at the INL have been using the > Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be > quite the shift for us. The thing is, that I've yet to successfully build > libMesh in debug mode using GCC on any ML box. We've tried numerous times > building the compilers from source, using MacPorts, and downloading them > for hpc.sourceforge.net. I keep thinking that we are doing something > wrong since I'm not seeing any chatter on this list about other devs having > issues. I believe that there are some real bugs in fparser that are really > hosing things up. With are hacks to the Makefile and our > object extensions it's sometimes possible to build in debug mode if you've > built in optimized mode first! > > So my question is, have you seen this issue? Can you configure libMesh > with fparser support and build in debug mode first (before you build > optimized mode) without issues? I'm able to replicate the problem on both > trunk and the automake branch and I now have the exact same configuration > as you do. > > Oh and Paul, if you are following along, note that I said that I'm seeing > the same problem in the automake branch now. When Jason ran the test the > other day, I told you it was working but it appears that is not the case. > I've tried numerous times and can always make it fail if the branch is > clean. We have a few issues with make clean at the root level which do not > clean up the fparser directory correctly. Nothing "git clean" can't fix > though ;) > > Let me know if you have any insights, > Thanks, > Cody > > >> As for the above comment - was that Paul saying there are problems with >> trunk but not the branch? Or is everyone happy now with both branch and >> trunk on Mountain Lion? >> >> I'm planning to merge the automake branch after the PECOS review later >> this >> month. >> >> -Ben >> >> >> >> >> > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-10-22 14:36:50
|
If it helps, the script I used to setup my port config is here: https://github.com/benkirk/Documents/blob/master/it/scripts/mac.sh On Oct 22, 2012, at 9:04 AM, "Cody Permann" <cod...@gm...<mailto:cod...@gm...>> wrote: On Mon, Oct 22, 2012 at 7:52 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: Cody, back to the subject though - Yeah, on the automake branch with macports gcc4.5 everyhing is ok, even in debug mode. I've tried with gcc4.6 and 4.7. I'll give 4.5 a shot. What happens when you run ./bootstrap ./contrib/bin/buildall.sh? Let me try it now and I"ll let you know. Cody -Ben On Oct 20, 2012, at 9:30 AM, "Cody Permann" <cod...@gm...<mailto:cod...@gm...>> wrote: On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <ben...@na...<mailto:ben...@na...>> wrote: >> Thought I'd follow up here. I've been working in libMesh trunk for awhile, so >> I hadn't tried out the branch on my laptop for some time. I did last night >> and >> these issues go away there (but they are still there in trunk). In >> particular, >> all examples run correctly and I can run everything (including my >> applications) with TBB on my Mac using built compilers etc. I don't have time >> to dig right now for what the difference is, but I thought I'd at least pass >> this along. (If I had to guess, the difference is either 1. libtool is >> stripping out some link flags that were causing the problem or 2. libtool is >> doing something different in how it links together the contributed libraries >> with the libMesh sources or 3. Something else). > > Interesting, I was just thinking about digging back through my mail to find > this issue since we just got the stack going this morning. It looks like the > majority of our applications are running just fine with our GCC stack (w/ > gfortran) on Mountain Lion! We also built Clang from source and it's also > working with gfortran as well so we are fairly pleased with these results. We > have only one issue right now but it should be fairly easy to sort out. It > has to do with our "plugin" system which does dynamic library loading but > other than that, everything else is working just fine. I'll let you know if > we run into that issue or if we see anything odd. So I'm now the proud owner of a mountain lion retina display, and spent most of yesterday setting up the machine. I have been able to install everything from MacPorts, including petsc/slepc, and run the libmesh.automake branch just fine. Ben, I just received my new Macbook Pro too and have similarly had a pleasant experience with the ease of installing everything I need through MacPorts. I do have one serious issue which is still plaguing me though. I've been chatting a bit with Paul off list but still haven't gotten to the bottom of the problem yet. Up 'til now, all of us at the INL have been using the Apple compilers (GCC 4.2.1 branch) so moving back to vanilla GCC will be quite the shift for us. The thing is, that I've yet to successfully build libMesh in debug mode using GCC on any ML box. We've tried numerous times building the compilers from source, using MacPorts, and downloading them for hpc.sourceforge.net<http://hpc.sourceforge.net>. I keep thinking that we are doing something wrong since I'm not seeing any chatter on this list about other devs having issues. I believe that there are some real bugs in fparser that are really hosing things up. With are hacks to the Makefile and our object extensions it's sometimes possible to build in debug mode if you've built in optimized mode first! So my question is, have you seen this issue? Can you configure libMesh with fparser support and build in debug mode first (before you build optimized mode) without issues? I'm able to replicate the problem on both trunk and the automake branch and I now have the exact same configuration as you do. Oh and Paul, if you are following along, note that I said that I'm seeing the same problem in the automake branch now. When Jason ran the test the other day, I told you it was working but it appears that is not the case. I've tried numerous times and can always make it fail if the branch is clean. We have a few issues with make clean at the root level which do not clean up the fparser directory correctly. Nothing "git clean" can't fix though ;) Let me know if you have any insights, Thanks, Cody As for the above comment - was that Paul saying there are problems with trunk but not the branch? Or is everyone happy now with both branch and trunk on Mountain Lion? I'm planning to merge the automake branch after the PECOS review later this month. -Ben |
From: Roy S. <roy...@ic...> - 2012-10-22 15:08:20
|
On Mon, 22 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote: > To be clear, 4.5 is a proper release. > > The issue is they distribute two packages - the peon version > consisting of two files (which we propose we move to) and the > developers version for Jose who want to muck with fparser. > > We presently have packaged the development version - the suggestion > is instead we package the peasant version. Ah, thanks for the clarification. I'd rather package the development version, even if we've no plans to muck with it, if only to make sure we stay GPL-compatible. Those .inc files are basically wads of intermediate bytecode, right? On the other hand, not breaking on OS X is definitely a higher priority, so let's switch back to release if we must. I like the "include both, selectable at configure-time" option best, if it's not too much work for Cody. In exchange I can finally get around to reproducing/fixing that Nemesis regression he found... --- Roy |