From: Roy S. <roy...@ic...> - 2011-02-28 22:18:54
|
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/lib...@li.../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 |
From: Roy S. <roy...@ic...> - 2011-10-31 14:29:10
|
On Mon, 31 Oct 2011, Andreas Günther wrote: > are you aware of any people, who have successfully build libMesh as dynamic > library in Microsoft Visual Studio under Windows? No. The last person I know who tried failed, but they were using a very old VC++ which didn't fully support the C++98 standards; with a new Visual Studio your biggest problem ought to be our various POSIX dependencies. > We are struggling with this issue. For external library use it seems to be > neccessary to "__declspec(dllexport)" all involved libMesh-classes and > -functions. But we do not intend to touch your code at all. Good luck. Let us know if there's anything reasonable we can do to patch the svn head to make that easier. E.g. obviously adding compiler-specific non-C++-isms is a no-no, but (barring other developers' disagreement) maybe adding a "LIBMESH_EXPORT" macro to function declarations that you could then #define to what you needed would be reasonable. We'd also like to add whatever Visual Studio project file does the equivalent build setup of our autoconf scripts. --- Roy |