Could not build on Ubuntu 14

[pravic]

So, here is a story.

Intro

Travis has only Precise and Trusty LTS versions (12 & 14) and Sciter does not work in there by default.

$ ./usciter ./usciter: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version CXXABI_1.3.8 not found ./usciter: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.21 not found

Dive

Let's check (click to expand)

> **$ ls /usr/lib/x86_64-linux-gnu/libstdc++.so.*** /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19 > **$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep CXXABI** CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_TM_1

-

So, Ubuntu 14 contains libstdc++ 6.0.19 by default, while Ubuntu 16 or higher 6.0.24:

Click to expand

> **$ ls /usr/lib/x86_64-linux-gnu/libstdc++.so.*** /usr/lib/x86_64-linux-gnu/libstdc++.so.6 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24 > **$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep CXXABI CXXABI_1.3 CXXABI_1.3.1 CXXABI_1.3.2 CXXABI_1.3.3 CXXABI_1.3.4 CXXABI_1.3.5 CXXABI_1.3.6 CXXABI_1.3.7 CXXABI_1.3.8 CXXABI_1.3.9 CXXABI_1.3.10 CXXABI_1.3.11 CXXABI_TM_1 CXXABI_FLOAT128

-

It looks like we need a newer libstdc++ version. Right? Partly.

Fix?

Let's try to install it:

$ sudo add-apt-repository ppa:ubuntu-toolchain-r/test
$ sudo apt-get update
$ sudo apt-get install libstdc++-7-dev
$ ls /usr/lib/x86_64-linux-gnu/libstdc++.so.*
/usr/lib/x86_64-linux-gnu/libstdc++.so.6  /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.24

Now we have 6.0.24 and Sciter works: ./usciter shows its fancy window.

Nope

But: the rust-sciter still can't be compiled:

$ cargo build --example first ... error: linking with cc failed: exit code: 1 = note: ./libsciter-gtk-64.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' collect2: error: ld returned 1 exit status

Whereas libstdc++ does contain the required GLIBCXX:

Click to expand

> **$ strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX** GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_3.4.11 GLIBCXX_3.4.12 GLIBCXX_3.4.13 GLIBCXX_3.4.14 GLIBCXX_3.4.15 GLIBCXX_3.4.16 GLIBCXX_3.4.17 GLIBCXX_3.4.18 GLIBCXX_3.4.19 GLIBCXX_3.4.20 GLIBCXX_3.4.21 GLIBCXX_3.4.22 GLIBCXX_3.4.23 GLIBCXX_3.4.24 GLIBCXX_DEBUG_MESSAGE_LENGTH

-

Summary

And now I am out of ideas.

I am still able to compile rust-sciter with a trick with RUSTFLAGS (export RUSTFLAGS='-C link-arg=-Wl,--unresolved-symbols=ignore-in-shared-libs'), but it will crash eventually during cargo test.

References

Apparently, GCC has introduced a so-called Dual ABI in 5.1: https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html and most of issues with GLIBCXX are pointed to that story with advice to update GCC / update libstdc++ / recompile with -D_GLIBCXX_USE_CXX11_ABI=0 and so on.

Nothing helps here, of course, we don't have C++ code to recompile.

The only thing I have noticed in differences between Ubuntu 14 and 16: if I update GCC, it will show a suspicious flag in its configuration: --disable-libstdcxx-dual-abi (gcc version 7.2.0 (Ubuntu 7.2.0-1ubuntu1~14.04)) while GCC 7 on 16 does not have it (gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3.2) ).

[pravic]

TLDR

Ubuntu 14.05 LTS (Trusty) with libstdc++.so.6.0.24:

$ cargo build --example first ... error: linking with cc failed: exit code: 1 = note: ./libsciter-gtk-64.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits, std::allocator >::_M_create(unsigned long&, unsigned long)@GLIBCXX_3.4.21' collect2: error: ld returned 1 exit status

Ubuntu 16, 17 with libstdc++.so.6.0.24 compile fine.

[pravic]

Well, I have disassembled and compared libstdc++ versions of 14 and 16 OS versions: the former is much smaller and does not contain symbols with std::__cxx11 namespace at all.

[pravic]

However, in a test C program using g++ instead of gcc resolves the linking. How come?