On Mon, Oct 22, 2012 at 7:52 AM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> 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" <codyperm...@gmail.com> wrote:
>
>
>
> On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <
> benjamin.kir...@nasa.gov> 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
>>
>>
>>
>>
>>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
