Dear all, it seems that the issue was due to a missing header file in Hilbert.hpp
After adding #include "Hilbert/Algorithm.hpp" everything went fine. I think the compiler was right since Algorithm.hpp is required to complete the definition of the function coordsToIndex. Probably this issue manifests only with the flag --enable-static. Thanks for help. Lorenzo On May 29, 2013, at 5:23 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: > > > On Wed, 29 May 2013, Lorenzo Alessio Botti wrote: > >> This is my clang version, I'm using xcode4.6.2, the most recent version. >> >> Apple clang version 3.0 (tags/Apple/clang-211.12) (based on LLVM 3.0svn) > > Thanks. It looks like neither gcc nor my clang 3.2 were tripping > the problem due to some accident of build order, but your clang 3.0 > does seem to be in the right here - fe_boundary.C instantiates a bunch > of FE functions, so the compiler might be allowed to decide "let's > instantiate the inline destructor here too", and the FEGenericBase > destructor needs more than just a forward declaration of the objects > it's destroying. > > I'm fixing it in trunk. > >> CXX src/apps/getpot_parse_opt-getpot_parse.o >> CXXLD getpot_parse-opt >> Undefined symbols for architecture x86_64: >> "Hilbert::coordsToIndex(CFixBitVec const*, int, int, CBigBitVec&)", >> referenced from: >> Hilbert::HilbertIndices (anonymous >> namespace)::get_hilbert_index<libMesh::Node>(libMesh::Node const*, >> libMesh::MeshTools::BoundingBox const&) in >> libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) >> Hilbert::HilbertIndices (anonymous >> namespace)::get_hilbert_index<libMesh::Elem>(libMesh::Elem const*, >> libMesh::MeshTools::BoundingBox const&) in >> libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) >> (anonymous namespace)::get_hilbert_index(libMesh::Point const&, >> libMesh::MeshTools::BoundingBox const&) in >> libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) >> ld: symbol(s) not found for architecture x86_64 >> clang: error: linker command failed with exit code 1 (use -v to see >> invocation) >> make[1]: *** [getpot_parse-opt] Error 1 >> make: *** [all-recursive] Error 1 > > Can you do whatever the Apple equivalent of nm is on your > libcontrib_opt and grep for coordsToIndex to see what's there? I'm > not sure whether that function isn't getting properly compiled into > your libcontrib or whether your libcontrib isn't getting properly > linked into libMesh apps. > --- > Roy ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
