>
> Bottom Line: I'm curious, does anyone have a completely working compiler
> that runs all examples in optimized and debug mode on OS X?
Yes, with macports gcc-4.5, macports petsc, and slepc.
libmesh.automake opt & debug both pass all tests
what petsc are you using?
I found an issue with i
Ben,
Are you able to run all of the libMesh examples (automake branch) with GNU
GCC on your mac? I've been chatting with Paul and he mentioned that
misc_ex6 seg faults (which we have confirmed here), but we are also seeing
a similar problem with adjoints_ex1. These problems aren't unique to the
>
> Ben, I just manually added those flags on my system and it's working fine,
> both the devel and release versions. I have GCC 4.6 but I'd be surprised if
> the issue was with 4.7 only. What error are you seeing?
thanks - it is 4.7 only, believe it or not…
I can recreate the issue with th
On Mon, Oct 29, 2012 at 9:51 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> wrote:
>
> On Oct 22, 2012, at 11:05 AM, Cody Permann wrote:
>
> >
> > 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 ge
>> This gets to the larger question of when we will require C++11,
>> which in my mind is probably a good year or so from now. In the
>> meantime, should we bother trying to track partially implemented
>> subsets?
>
> Using C++11 (or TR1) when it's available can be beneficial for making
> sure t
On Mon, Oct 29, 2012 at 11:08 AM, Roy Stogner wrote:
>
> Actually *requiring* C++11, I'd prefer to wait for another year or two
> at least; last time I checked (which admittedly was a while ago) even
> Intel wasn't entirely up to spec yet, and I'll bet there's people
> stuck on older icpc and othe
On Mon, 29 Oct 2012, Kirk, Benjamin (JSC-EG311) wrote:
> This gets to the larger question of when we will require C++11,
> which in my mind is probably a good year or so from now. In the
> meantime, should we bother trying to track partially implemented
> subsets?
Using C++11 (or TR1) when it's
On Oct 22, 2012, at 11:05 AM, Cody Permann wrote:
>
> 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...
>
> Sounds good to me! Based on my
On Mon, Oct 22, 2012 at 9:08 AM, Roy Stogner wrote:
>
> 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
>> developer
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 prese
On Mon, 22 Oct 2012, Cody Permann wrote:
> On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311)
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 sou
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"
mailto:[email protected]>> wrote:
On Mon, Oct 22, 2012 at 7:52 AM, Kirk, Benjamin (JSC-EG311)
mailto:benjamin.ki
On Mon, Oct 22, 2012 at 7:52 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> 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 happe
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"
mailto:[email protected]>> wrote:
On Wed, Oct 3
On Sat, Oct 20, 2012 at 9:56 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> 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 us
>>
>> 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 r
On Sat, Oct 20, 2012 at 8:56 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> 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
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"
ma
On Wed, Oct 3, 2012 at 7:34 AM, Kirk, Benjamin (JSC-EG311) <
[email protected]> 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 th
>> 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 ev
On Wed, Sep 26, 2012 at 8:24 AM, Paul T. Bauman wrote:
> On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman 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 su
On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman 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 wor
On Thu, Sep 20, 2012 at 10:25 AM, Paul T. Bauman wrote:
> On Thu, Sep 20, 2012 at 10:53 AM, Cody Permann 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
On Thu, Sep 20, 2012 at 10:33 AM, Paul T. Bauman wrote:
> On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann 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 co
On Thu, Sep 20, 2012 at 11:19 AM, Cody Permann 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 appropria
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 versi
On Thu, Sep 20, 2012 at 10:53 AM, Cody Permann 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 thi
On Thu, Sep 20, 2012 at 10:02 AM, Roy Stogner 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?
(should read i am not yet running mountain lion)
On Sep 20, 2012, at 10:15 AM, "Kirk, Benjamin (JSC-EG311)"
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 upda
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.
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
Reply to Cody coming...
On Thu, Sep 20, 2012 at 11:02 AM, Roy Stogner 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.
--
E
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
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
34 matches
Mail list logo
