aws-taylor commented on issue #17589:
URL:
https://github.com/apache/incubator-mxnet/issues/17589#issuecomment-680287164
```_ZN4dmlc14RecordIOReader10NextRecordEPSs``` corresponds to
```dmlc::RecordIOReader::NextRecord(std::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)```
I ran into this problem because I was compiling MxNet with GCC 8 but linking
to a 4.9 libstdc++. Somewhere between 4.9 and 8, there was an ABI change to
std::string in order to comply with C++11 requirements that resulted in
std::string being moved into the **std::__cxx11** namespace. You can see this
below (T ~= 'defined', 'U' ~= missing):
```
>> nm -C libmxnet.so | grep 'dmlc::RecordIOReader::NextRecord'
000000000471cc60 T
dmlc::RecordIOReader::NextRecord(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*)
0000000000cd897c t
dmlc::RecordIOReader::NextRecord(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >*) [clone .cold.54]
U dmlc::RecordIOReader::NextRecord(std::string*)
```
If you look in libmxnet.so, you'll find tons of similarly missing symbols.
For whatever reason, NextRecord(...) just happens to be the first in the
compilation.
Normally it is possible to force GCC to compile using the old, pre-C++11
namespace by compiling with ```-D_GLIBCXX_USE_CXX11_ABI=0```, however there
appears to have been a bug in MxNet that didn't forward CXX_FLAGS to the build
correctly. I haven't tracked down precisely which commit fixed the problem, but
if you run into this issue, try using a newer commit or make sure that your GCC
and libstdc++ versions are compatible.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
