Actually there is no difference in the libraries being linked to; that was an erroneous report. Both MOOSE and the libmesh example link to both libhdf5_hl and libhdf5. (I'm still curious why both libraries get linked when only -lhdf5 was specified; I clearly don't know enough about this.)
I guess this only makes it more puzzling to me why for the same arguments to `exII::ex_create`, I get an error return code for MOOSE and not for the libmesh example. On Mon, Jul 15, 2019 at 8:33 PM Alexander Lindsay <alexlindsay...@gmail.com> wrote: > This is some interesting stuff. Ok here's stepping through the > system_of_equations example 3, which calls exodus file writing methods: > > (lldb) > Process 45495 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = step over > frame #0: 0x00000001008b039c > libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x000000010d01b800, > filename="out.e") at exodusII_io_helper.C:1207 > 1204 mode |= EX_NOCLASSIC; > 1205 #endif > 1206 > -> 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws, > &io_ws); > 1208 > 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file."); > 1210 > Target 0: (example-dbg) stopped. > (lldb) p mode > (int) $1 = 584 > (lldb) p comp_ws > (int) $2 = 8 > (lldb) p io_ws > (int) $3 = 8 > (lldb) p filename.c_str() > (const std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> >::value_type *) $4 = 0x00007ffeefbfdc29 "out.e" > (lldb) n > Process 45495 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = step over > frame #0: 0x00000001008b03cb > libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x000000010d01b800, > filename="out.e") at exodusII_io_helper.C:1209 > 1206 > 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws, > &io_ws); > 1208 > -> 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file."); > 1210 > 1211 if (verbose) > 1212 libMesh::out << "File created successfully." << std::endl; > Target 0: (example-dbg) stopped. > (lldb) p ex_id > (int) $5 = 65536 > > And then here is MOOSE's simple_diffusion: > > (lldb) > Process 45477 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = step over > frame #0: 0x000000010758d39c > libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x0000000111831e00, > filename="simple_diffusion_out.e") at exodusII_io_helper.C:1207 > 1204 mode |= EX_NOCLASSIC; > 1205 #endif > 1206 > -> 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws, > &io_ws); > 1208 > 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file."); > 1210 > Target 0: (moose_test-dbg) stopped. > (lldb) p mode > (int) $0 = 584 > (lldb) p comp_ws > (int) $1 = 8 > (lldb) p io_ws > (int) $2 = 8 > (lldb) p filename.c_str() > (const std::__1::basic_string<char, std::__1::char_traits<char>, > std::__1::allocator<char> >::value_type *) $3 = 0x00007ffeefbfdbb9 > "simple_diffusion_out.e" > (lldb) n > Exodus Library Error: [ex_create] > Error: file create failed for simple_diffusion_out.e in NETCDF4 and > CLOBBER mode. > This library probably does not support netcdf-4 files. > exerrval = 13 > Process 45477 stopped > * thread #1, queue = 'com.apple.main-thread', stop reason = step over > frame #0: 0x000000010758d3cb > libmesh_dbg.0.dylib`libMesh::ExodusII_IO_Helper::create(this=0x0000000111831e00, > filename="simple_diffusion_out.e") at exodusII_io_helper.C:1209 > 1206 > 1207 ex_id = exII::ex_create(filename.c_str(), mode, &comp_ws, > &io_ws); > 1208 > -> 1209 EX_CHECK_ERR(ex_id, "Error creating ExodusII mesh file."); > 1210 > 1211 if (verbose) > 1212 libMesh::out << "File created successfully." << std::endl; > Target 0: (moose_test-dbg) stopped. > (lldb) p ex_id > (int) $4 = -1 > > The arguments into exII::ex_create (except for the name of course) are the > exact same!! > > So if I look into the hdf5 libraries that the different executables are > dynamically linking to I get different libraries: > > $ otool -L moose_test-dbg | grep hdf5 > /Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5_hl.100.dylib > (compatibility version 102.0.0, current version 102.2.0) > /Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5.103.dylib > (compatibility version 105.0.0, current version 105.0.0) > > $ otool -L example-dbg | grep hdf5 > /Users/lindad/hdf5/build-1.10.5/../installed-1.10.5/lib/libhdf5_hl.100.dylib > (compatibility version 102.0.0, current version 102.2.0) > > The moose executable is somehow linking to multiple hdf5 libraries, one > the traditional library and the other the "high level" library. The libmesh > executable only links to the high level. This is despite the fact that they > are using the exact same linking flags: > > -Wl,-rpath,/Users/lindad/projects/moose/scripts/../libmesh/installed-hdf5-1.10.5/lib > -L/Users/lindad/projects/moose/scripts/../libmesh/installed-hdf5-1.10.5/lib > -lmesh_dbg -L/Users/lindad/hdf5/installed-1.10.5/lib -lhdf5 > -Wl,-rpath,/Users/lindad/hdf5/installed-1.10.5/lib > -L/Users/lindad/projects/moose/petsc/arch-moose/lib > -Wl,-rpath,/Users/lindad/projects/moose/petsc/arch-moose/lib > -Wl,-rpath,/opt/X11/lib -L/opt/X11/lib > -Wl,-rpath,/opt/moose/mpich-3.3/clang-8.0.0/lib > -L/opt/moose/mpich-3.3/clang-8.0.0/lib -Wl,-rpath,/opt/moose/llvm-8.0.0/lib > -L/opt/moose/llvm-8.0.0/lib > -Wl,-rpath,/opt/moose/gcc-8.3.0/lib/gcc/x86_64-apple-darwin18.5.0/8.3.0 > -L/opt/moose/gcc-8.3.0/lib/gcc/x86_64-apple-darwin18.5.0/8.3.0 > -Wl,-rpath,/opt/moose/gcc-8.3.0/lib -L/opt/moose/gcc-8.3.0/lib > -Wl,-rpath,/opt/moose/llvm-8.0.0/lib/clang/8.0.0/lib/darwin > -L/opt/moose/llvm-8.0.0/lib/clang/8.0.0/lib/darwin -lpetsc -lHYPRE -lcmumps > -ldmumps -lsmumps -lzmumps -lmumps_common -lpord -lscalapack -lsuperlu_dist > -lflapack -lfblas -lparmetis -lmetis -lptesmumps -lptscotchparmetis > -lptscotch -lptscotcherr -lesmumps -lscotch -lscotcherr -lX11 -lmpifort > -lgfortran -lgomp -lquadmath -lc++ -lmpicxx -lmpi -lpmpi -lomp > -lclang_rt.osx -lm -lz -lstdc++ -ldl > > I simply don't understand why the hdf5_hl library would get picked up in > either case. Shouldn't I have to specify -lhdf5_hl in order for that to > happen? > > > On Sun, Jul 14, 2019 at 5:10 PM John Peterson <jwpeter...@gmail.com> > wrote: > >> Regarding HDF versions, I can’t remember exactly what we are using at the >> moment but I think it’s 1.8.x? I will check and get back to you. >> >> On Jul 14, 2019, at 5:00 PM, John Peterson <jwpeter...@gmail.com> wrote: >> >> There isn’t a lot of logic behind what gets updated when beyond “as >> necessary”. The most recent netcdf update fixed an issue with writing hdf5 >> files for us. I didn’t update exodusII at the time since it there was no >> specific issue that needed to be addressed, but it is quite old relative to >> what’s available on github, so it should probably be done at some point. >> >> >> On Jul 14, 2019, at 4:35 PM, Alexander Lindsay <alexlindsay...@gmail.com> >> wrote: >> >> So I didn't get any replies to this >> <https://sourceforge.net/p/libmesh/mailman/message/36709086/>, but now >> I'm getting more curious. I'm curious why we fairly consistently update our >> netcdf version, but seem to never update our exodusii contrib? Are we sure >> that everything is compatible? I ran `make check` on my personal build of >> netcdf 4.6.2 with hdf5-1.10.5 and all tests pass, so I'm wondering whether >> the incompatibility may be at a higher level? Is our older exodusii source >> using "incorrect" APIs in the newer netcdf versions when hdf5 is available? >> >> I can look this up, but what does netcdf do differently when hdf5 is or >> is not enabled in our configure? >> >> _______________________________________________ >> Libmesh-devel mailing list >> Libmesh-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> >>
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
