Copying this to libmesh-devel and libmesh-users; I don't think I see
the answer (or even any productive way to debug such a problem)
myself, I'm afraid...
On Mon, 28 Feb 2011, Andreas Günther wrote:
the Libmesh problem I observe reminds me of the problem described in
http://www.mail-archive.com/[email protected]/msg02728.html
but I'm not sure about if its caused by the same thing.
For test purposes I check, if a point in 3D is inside a certain hexahedron.
For certain points I get wrong results. Debugging my program reveals that
const unsigned int n_sf = FE<Dim,LAGRANGE>::n_shape_functions(type, order);
in line 538 of fe-map.cpp is 4 instead of 8 (for HEX8, FIRST). This is
fe_map.C, I assume?
because the later called n_dofs-function jumps into the implementation of
fe_xyz.cpp instead of fe_lagrange.cpp although the template parameters are 3,
LAGRANGE. The compiler doesn't complain. It seams to be a linkage problem for
the several implemented n_dofs-functions.
The strange thing is, that this problem is not observed in a
libmesh-stand-alone-testprogram (statically linked).
How about in the libMesh test programs when dynamically linked? We
don't run any 3D examples by default but there are several that can be
switched to use HEX8 by tweaking a config file.
I'd like to use libmesh inside another software, so I recompiled the
whole library and load the shared objected whenever needed. Under a
Windows machine even this worked fine. But under Linux I get this
run-time garbage.
I am using gcc version 4.3.2 within an AMD64-machine.
Investigating the shared objects
nm liblibmesh.so (library for other software)
and
nm libmesh.so (stand-alone)
provide the same "Weak-Symbols" for n_dofs:
000000000040d046 W libMesh::FE<0u,
(libMeshEnums::FEFamily)0>::n_dofs(libMeshEnums::ElemType,
libMeshEnums::Order)
00000000004392f4 W libMesh::FE<0u,
(libMeshEnums::FEFamily)1>::n_dofs(libMeshEnums::ElemType,
libMeshEnums::Order)
....
in the same order. So maybe (since the compiler doesn't complain) the
so-files are okay and its truely a linkage problem.(?)
Just to double-check, that "...." includes the FE<3u,etcetera>::n_dofs
versions too, right?
Could it be a compiler flag-issue, since our software tells Libmesh how to
build (and not the configure-script)?
Try building libMesh in devel mode and see if the problem still occurs
there too? If it does then at least it might be easier to see the
intermediate stages of what's going wrong.
Otherwise I'm not sure what's to be done short of running the object
files through a disassembler and seeing whether the compiler or the
linker has messed up.
Does my observed problem reminds you of a certain flag, I have
missed out?
I'm afraid not. We hardcode the values of the FEFamily enums to the
same numbers regardless of configure options, so even if you had
different object files being compiled with different flags, it still
shouldn't have effected how n_dofs gets dispatched.
I guess that's a virtual function call, though... so perhaps if the
FE headers got compiled with completely different options in different
object files, the vtable usage might be completely screwed up? I'd
still think that as long as everything was using the same
libmesh_config.h then you'd be fine.
...
Whatever build system you've replaced our configure script with, it
does generate a valid libmesh_config.h?
---
Roy
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
