glibc_version_header icon indicating copy to clipboard operation
glibc_version_header copied to clipboard

libstdc++ solution?

Open AndrewBelt opened this issue 5 years ago • 4 comments

In the README, you mention

If you want C++, you'll need to build libstdc++ with this enabled. That can be a little involved, but I'm working on a solution, to be available "soon".

I'm interested in what your ideas are for libstdc++. Is it as simple as generating a header of symvers for libstdc++ versions?

AndrewBelt avatar May 23 '19 18:05 AndrewBelt

Is it as simple as generating a header of symvers for libstdc++ versions?

No, that won't work. In libstdc++ there is only one version of a given symbol, so it's not possible to force it to bind to an older version.

The typical problems with libstdc++ library versions are due to entirely new symbols added to libstdc++.so.6 not with new versions of symbols. And if you compile using a new GCC and its new libstdc++, such that you depend on new symbols in that release of libstdc++, then no amount of messing with symbol versions is going to make the new symbols present in an older libstdc++.so.6. They just aren't present.

There are two correct solutions: either build with an old GCC so you only depend on an old libstdc++.so, or use something like Red Hat's devtoolset, which provides a new GCC with (most) new C++ features supported, but doesn't introduce dependencies on a new libstdc++.so (so it runs on older systems).

jwakely avatar Sep 12 '19 09:09 jwakely

use something like Red Hat's devtoolset, which provides a new GCC with (most) new C++ features supported, but doesn't introduce dependencies on a new libstdc++.so (so it runs on older systems).

Why doesn't every distribution do it this way by default?

probonopd avatar Sep 12 '19 17:09 probonopd

It creates bigger executables, and not all features of the new GCC are available when using that linkage model, and not everybody needs to be compatible with old, frozen ABIs.

jwakely avatar Sep 12 '19 20:09 jwakely

Hello, Have you successfully built and compiled ".so" libs cross different systems ( .,i,e: different gcc version) ? I investigated hard on this but failed at all. Which a lot of errors like: undefined reference to `VTT for std::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >@GLIBCXX_3.4.21' This error comes from the incompatible gcc version.

quocnhat avatar Jul 20 '20 07:07 quocnhat