On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <email@example.com>
>> 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
>> these issues go away there (but they are still there in trunk). In
>> 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 findSo I'm now the proud owner of a mountain lion retina display, and spent most
> 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.
of yesterday setting up the machine. I have been able to install everything
from MacPorts, including petsc/slepc, and run the libmesh.automake branch
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,
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