prebuilt环境可能是ubuntu18, 这里只记录一些参考的分析
--->实际是链接器不同导致的,指定的llvm而不是系统默认的链接器,至于为什么使用lld有问题,还没分析清楚;
参考:
terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_M_construct null not valid Aborted (core dumped)
https://root-forum.cern.ch/t/root-on-freebsd-again/26806/9
https://stackoverflow.com/questions/11682748/is-clang-abi-same-as-g
根据clang libc ++页面，他们的目标是
与gcc的libstdc ++的ABI兼容，可用于某些底层功能，例如异常对象，rtti和内存分配。
这似乎暗示他们并不是针对100％的兼容性。例如，在该页面上，他们还说：
通过多年的经验（包括之前实现过标准库），我们学到了很多有关实现标准容器的事情，这些事情需要ABI破损以及实现方式的根本变化。例如，对于多核计算机（尤其是在具有右值引用的C ++'0x中），使用“短字符串优化”而不是使用写时复制（COW）构建std :: string是一种较好的方法，这是公认的。已确定破坏与旧版本库的ABI兼容性对于实现libc ++的性能目标至关重要。
我相信GCC仍在使用引用计数的COW，因此clang似乎并不担心与ABI的兼容性std::string（与较旧的clang编译的二进制文件或与GCC兼容）。
https://stackoverflow.com/questions/60836246/standard-library-abi-compatibility
https://stackoverflow.com/questions/41745527/cannot-view-stdstring-when-compiled-with-clang
https://www.coder.work/article/3287082
https://blog.csdn.net/jindingwang/article/details/7569466
https://blog.csdn.net/fly_time2012/article/details/78482323
https://blog.csdn.net/itas109/article/details/106751869
libc++我认为这与Clang不同。为什么anwser专注于标准库兼容性，而不是语言二进制兼容性？很明显，它们对方法使用相同的调用约定，它们在堆栈上返回对象，并且通常在语言级别上是二进制兼容的吗？ – cubuspl42 2014年 6月22日0:48clang++ -stdlib=libstdc++将生成与g ++ 100％ABI兼容的代码。但是，如今，clang-stdlib=libc++默认使用（而不是stdlibc++）。因此，尽管在发布时是错误的，但此答案在随后的几年中意外地变得正确了，至少在OSX上是如此。（编写此答案时，clang的默认设置为-stdlib=libstdc++，因此默认情况下二进制文件与g ++兼容。） – Stuart Berg 15年9月24日在17:45