From: Sebastian Steiger <steiger@pu...> - 2010-08-13 11:29:41
While trying to statically link my application which uses libmesh I
discovered that there is an int main() in libtetgen.a:
| grep main
000000000004c0f0 T main
I think the solution is to define TETLIBRARY during the compilation of
tetgen (see tetgen.C).
I use version 0.6.4 of libmesh.
From: Roy Stogner <roystgnr@ic...> - 2010-08-19 03:33:05
On Fri, 13 Aug 2010, Sebastian Steiger wrote:
> While trying to statically link my application which uses libmesh I
> discovered that there is an int main() in libtetgen.a:
> steiger@...:~/src/app-nemo/NEMO$ nm
> | grep main
> 000000000004c0f0 T main
> I think the solution is to define TETLIBRARY during the compilation of
> tetgen (see tetgen.C).
This looks correct, but it's pretty surprising; I don't see why an
extra copy of main doesn't screw up dynamic linking too.
Looks like our tetgen Makefile was defining TRILIBRARY instead; an
anachronism copied over from the triangle library support I assume.
It's fixed in svn now.
From: Roy Stogner <roystgnr@ic...> - 2010-08-19 15:15:43
On Thu, 19 Aug 2010, Sebastian Steiger wrote:
> Thanks for looking into this. Actually there is another int main() in
> libnemesis, but I don't know how to fix it.
It looks like the only thing in ne_test.c is that main() and some
test-utility-specific supporting routines. I'll just change our
nemesis Makefile to exclude ne_test.c from the sources list.
From: Roy Stogner <roystgnr@ic...> - 2010-08-25 01:26:09
On Tue, 24 Aug 2010, Sebastian Steiger wrote:
> While valgrinding our software I discovered the following error (running on a
> single machine):
> ==3358== Invalid write of size 4
> ==3358== at 0x586E8BA: libMesh::MeshBase::n_subdomains() const
> ==3358== by 0x586F845: libMesh::MeshBase::get_info() const
> ==3358== by 0x586FE50: libMesh::MeshBase::print_info(std::ostream&) const
> ==3358== by 0x40BB1B: test_1D_integration::test_method()
> Looking at the code:
> template <typename T>
> inline void allgather(T send,
> std::vector<T> &recv,
> const Communicator &comm)
> START_LOG ("allgather()","Parallel");
> if (comm.size() > 1)
> MPI_Allgather (&send,
> recv = send;
> STOP_LOG ("allgather()","Parallel");
> Line 2629 is the 'recv = send' statement. It seems like that vector has
> length 0 when being run on a single CPU. I checked the svn log a little and
> it seems like there have been modifications in the past few months - not 100%
> sure though if it's not my problem...
The problem isn't in allgather - there recv gets sized to comm.size(),
which should never be 0 on a Communicator that proxies anything except
It looks like here n_subdomains() is calling set_union() which is
calling gather() which is calling all_gather(). There's actually a
bug I'll now fix here (some of those Parallel:: functions aren't
passing their input Communicator along properly), but that shouldn't
be a problem in the n_subdomains() case where the default COMM_WORLD
proxy is being used.
Can you check and make sure your Communicator_World._size is properly