undefined reference to `conduit::Node::name[abi:cxx11]() const'

[yurivict]

: && /usr/local/libexec/ccache/g++11 -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11  -Wl,-rpath=/usr/local/lib/gcc11 -g -Wall -Wextra -Wno-unused-parameter -Wnon-virtual-dtor -Wshadow -Wno-deprecated-declarations -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11  -Wl,-rpath=/usr/local/lib/gcc11  -DNDEBUG -lconduit -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11 -L/usr/local/lib/gcc11 data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/generate_schema_and_sample_list.cpp.o data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/helpers.cpp.o -o bin/generate_schema_and_sample_list  -Wl,-rpath,/usr/local/lib:  /usr/local/lib/libconduit_relay.so  -lpthread  /usr/local/lib/libhdf5.so.200.2.0  -ldl  -lrt  /usr/local/lib/libsiloh5.so  -lm  -ldl  -lrt  /usr/local/lib/libsiloh5.so  -lm  /usr/local/lib/libconduit_blueprint.so  /usr/local/lib/libconduit.so && :
/usr/local/bin/ld: data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/generate_schema_and_sample_list.cpp.o: in function `build_node_from_file(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/generate_schema_and_sample_list.cpp:59: undefined reference to `conduit::relay::io::load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, conduit::Node&)'
/usr/local/bin/ld: /disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/generate_schema_and_sample_list.cpp:61: undefined reference to `conduit::relay::io::load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, conduit::Node&)'
/usr/local/bin/ld: data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/generate_schema_and_sample_list.cpp.o: in function `write_yaml_file(std::ostream&, conduit::Node const&, int, int)':
/disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/generate_schema_and_sample_list.cpp:123: undefined reference to `conduit::Node::name[abi:cxx11]() const'

Revision: 0.102-254-g2e3012a9a
gcc-11
FreeBSD 13.1

[yurivict]

It also fails to find other conduit symbols:

/disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/generate_schema_and_sample_list.cpp:246: undefined reference to `conduit::relay::io::identify_protocol(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
/usr/local/bin/ld: data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/helpers.cpp.o: in function `(anonymous namespace)::get_matching_node_paths_impl(conduit::Node const&, conduit::Schema const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&)':
/disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/helpers.cpp:12: undefined reference to `conduit::Node::path[abi:cxx11]() const'
/usr/local/bin/ld: data_utils/hdf5/CMakeFiles/generate_schema_and_sample_list.dir/helpers.cpp.o: in function `data_utils::get_prototype_sample(conduit::Node const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)':
/disk-samsung/freebsd-ports/misc/lbann/work/lbann-0.102-254-g2e3012a9a/data_utils/hdf5/helpers.cpp:65: undefined reference to `conduit::Node::fetch_existing(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const'

[benson31]

How did you build conduit? Or more directly: what do you get from nm /usr/local/lib/libconduit_relay.so | grep 'identify_protocol' | c++filt? I'm guessing there's a C++ ABI incompatibility issue with std::string, probably resulting from different handling of the C++ standard across the two packages.

[yurivict]

$ nm work/stage/usr/local/lib/libconduit_relay.so | grep identify_protocol | c++filt
00000000000a74e0 T conduit::relay::io::identify_protocol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&)
00000000000ac670 T conduit::relay::io::blueprint::detail::identify_protocol(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)

[yurivict]

conduit was built from the FreeBSD port using clang-14.
clang-14 crashes on one of the files in lbann, so I used gcc-11.
Maybe gcc has different handling of symbols.

[benson31]

Yeah, this is almost certainly the result of different symbols being used for std::string between the two packages. I don't know that there's anything we can do about that on the LBANN side of things.

When I split the chain between clang and GCC like this, I try to use clang++ --gcc-toolchain=/path/to/gcc/prefix as the "Clang compiler" -- it at least seems to minimize the likelihood of things like this...

clang-14 crashes on one of the files in lbann

That's unfortunate. I'm partial to Clang in general and I haven't been having any issues lately. I'm curious about what's going on there... But that's probably a different issue.

[yurivict]

There is the "-g" compiler flag left in Release build - it causes clang to crash. Clang crashes in debug info generation.

[benson31]

Huh, come to think of it I've seen this on Darwin. I haven't had time to do the deep-dive I want to do on that (it's not really my problem to solve; I'm just interested). I think I put in some CMakery to avoid -g when building on Apple; I could expand that to all BSD-y things.

[yurivict]

"-g" shouldn't generally appear in Release builds. It would be interesting to find where it is coming from and remove it there.

[benson31]

I agree, but it's the general preference of most of our users to have -O3 and -g. Our tools all add it at every compilation level so that we always get good stack traces (or as good as they can be, I guess). It shouldn't make any difference whatsoever (except in the final binary size), so it's really a Clang+BSD issue that this is happening. I don't see it with Clang 14 or Clang 15 on any of our Linux systems.