On Tue, 1 Mar 2011, Andreas Günther wrote:
Manually changing this order (fe_lagrange.o first, later fe_xyz.o) fixes the problem!!! (for my certain test setting, but not the whole library of course).Does the Libmesh library intrinsically requires a certain object order for linking? For me it seems so due to the multiple definition of the same n_dofs-function.
Wow. It's not *intended* to require a certain object order for linking, but clearly it *does* require that order. I think I may be starting to understand the problem. fe_xyz.C (like pretty much every FE class) uses FE<Dim,LAGRANGE>::n_shape_functions when working on the geometric mapping, which is always Lagrange. But how does it instantiate that function? Well, it inlines to a call to n_dofs, and there's a handy FE<Dim,T>::n_dofs definition elsewhere in fe_xyz.C... we only explicitly instantiate that for T=XYZ, but the compiler must create a T=LAGRANGE instantiation implicitly when needed. The fix to make those FE instantiations more robust is probably going to be simple but horribly long... since it's working with our standard build system and you've found a workaround for your system, I'll get to it as soon as I find time. --- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
