On Mon, Aug 5, 2013 at 8:58 AM, Manav Bhatia <bhatiamanav@...> wrote:
> On Mon, Aug 5, 2013 at 10:49 AM, John Peterson <jwpeterson@...:
>> On Mon, Aug 5, 2013 at 6:51 AM, Manav Bhatia <bhatiamanav@...:
>>> hmm... trying to figure that out myself.
>>> I have not upgraded the compilers, except my macports gcc from 4.7 ->
>>> I don't see why that would affect this behavior since I am not using this
>>> compiler. (Not to imply that there couldn't be other issues at my end.)
>> Does any of your software stack (MPI/PETSc/etc) come from macports, or
>> have you hand-built everything with system GCC?
>> Honestly I'm surprised that system GCC has been working for you at all...
>> we have been using hand-built GCC since I think Lion because of weird
>> segfaults in system-level libraries like this.
>> Obviously I'm not 100% certain, but I don't think there's any way that
>> libmesh code is causing a segfault in localtime().
> I use only MPI from macports. I am not sure which compiler macport uses to
> build MPI, but I am going to guess it uses the macport gcc.
> I handbuilt petsc and slepc, but it uses the system gcc, while my libmesh
> builds have been using clang++ (boy, what a hodge-podge of compilers at my
> I don't know what to say about clang... maybe I got luck so far. At the
> moment, I have recompiled my library with perflog disabled so that I can
> finish some things at my end. Will get back to this issue in a couple of
> days. It is still puzzling though...
My fault, I misunderstood that you were using clang and not system GCC. I
don't fully recall, but I think clang worked a bit better for us than
system GCC but wasn't perfect... some of our devs currently use clang, but
a hand-built clang not the Apple one.
Anyway, I would certainly attempt to use *the same* set of compilers for
your whole stack if possible. Mixing compilers probably isn't an issue for
C, but I really wouldn't trust any mixing of C++ compilers...