On May 28, 2013, at 2:36 PM, Derek Gaston wrote:
> Ben - are you saying I need to apply that patch? Has that patch been removed
> - I thought that was still in there right now….
What is in there right now is
// Construct singletons who may be at risk of the
// "static initialization order
We run all of our tests through Valgrind for every change - so it's not a
normal thing. Definitely something to do with the way they're linking
stuff together
Ben - are you saying I need to apply that patch? Has that patch been
removed - I thought that was still in there right now
Derek
On Tue, 28 May 2013, Derek Gaston wrote:
A large project recently sucked in MOOSE (and therefore libMesh) into a much
larger code-base... and they are seeing issues with the new singleton stuff.
Here's just a snippet from a debug build run through Valgrind.
==9467== Invalid write of size 8
==
On May 28, 2013, at 2:07 PM, Derek Gaston wrote:
> Any ideas on stuff they can do to mitigate this?
It's not clear to me that it is a singleton issue from the trace - is that
problem inside the communicator constructor?
But anyway, a workaround for the Singleton auto-construction is to make s
A large project recently sucked in MOOSE (and therefore libMesh) into a
much larger code-base... and they are seeing issues with the new singleton
stuff. Here's just a snippet from a debug build run through Valgrind.
==9467== Invalid write of size 8
==9467==at 0x61912DB:
__gnu_debug::_Safe_se
On May 28, 2013, at 1:29 PM, John Peterson wrote:
>
> PS Forwarding this to the libmesh-devel list in case other people have
> suggestions/similar problems.
There is a known issue https://github.com/libMesh/libmesh/issues/97 that causes
the following to be broken:
$ ./configure …
$ make
$ m
On Tue, May 28, 2013 at 10:22 AM, Shiyuan Gu wrote:
> Dear John,
> I built a libmesh from git-hub. I didn't recognize any errors in the
> compilation and building process. However, when I tried to build the
> examples, I failed due to a wrong path to netcdf.la.
>
> libtool: link: cannot find
