Skip to content
Latchkey

Linker ABI mismatch "_GLIBCXX_USE_CXX11_ABI" in CI

libstdc++ has two ABIs for strings and some containers, selected by _GLIBCXX_USE_CXX11_ABI. When a prebuilt library uses one ABI and your CI-built objects use the other, symbols like std::__cxx11::basic_string do not match and the link fails with undefined references.

What this error means

The link stage fails with "undefined reference to" a symbol containing __cxx11 (or missing it), typically after pulling a prebuilt package built with a different ABI than the runner compiler defaults to.

ld
undefined reference to `foo(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status

Common causes

A prebuilt library uses the other ABI

A dependency compiled with _GLIBCXX_USE_CXX11_ABI=0 (old ABI) will not link against runner code built with the default new ABI, and vice versa.

Mixed toolchains across the dependency graph

A binary package built on an older distro and your newer runner compiler disagree on the string ABI, breaking the link.

How to fix it

Match the ABI to the prebuilt library

Set the same _GLIBCXX_USE_CXX11_ABI value your prebuilt dependency was compiled with.

Terminal
g++ -D_GLIBCXX_USE_CXX11_ABI=0 main.cc -o app -lfoo

Rebuild the dependency from source

Build the dependency with the same toolchain (for example Conan --build=missing) so both sides share one ABI.

Terminal
conan install . --build=missing

How to prevent it

  • Build all C++ dependencies with the same toolchain and ABI in CI.
  • Prefer building from source over mixing prebuilt binaries across distros.
  • Set _GLIBCXX_USE_CXX11_ABI consistently across the whole build.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →