I guess this is no good digihabia:libmesh-0.9.1 ihabia$ nm contrib/libcontrib_opt_la-cppsource.o 0000000000000028 s EH_frame0 0000000000000000 T __ZN53something_obscure_That_wont_ever_conflictWithAnything14i_am_worthlessEv 0000000000000040 S __ZN53something_obscure_That_wont_ever_conflictWithAnything14i_am_worthlessEv.eh
I also updated the compilers... Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) Target: x86_64-apple-darwin12.3.0 Thread model: posix 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 ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
