-
-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible libstdc++ incompatibility on Linux #388
Comments
cc: @jakirkham |
Thanks @gqmelo. I think I missed some of the details in our chat earlier. So it is nice to seem them laid out here. When building with |
I forgot this very important detail. Yeah, the code compiled with gcc 5.x used But anyway, this actually does not matter, as it is not my C++ code that is triggering the crash. It's mesa's and llvm's. Actually I can reproduce the crash with a pure C program Maybe a diagram makes it easier to understand:
What's important on the diagram above is that calls to C++ API can be executed either on Looking into libstdc++ source code, |
@gqmelo Hence, as suggested in your post I tried to build libstdc++ with newer binutils 2.31.1 https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.bz2 but still the cope of “_S_empty_rep_storage” remains as “w” Can you tell me with which binutils you are compiling libstdc++.? Or can you suggest anything else to resolve my issue ? FYI, I am using gcc-4.7.3 and building it against glibc-2.2.5. Attached bash script explain how I am compiling gcc #0 0x00007ffff7611428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 at ../csu/libc-start.c:247 #17 0x0000000000408fa9 in _start () |
My general understanding is that conda cannot guarantee ABI compatibility if users set |
I replied by email as that doesn't seem to be directly related to conda-forge, but just to reinforce here that static linking to libstdc++ is a bad idea. The bug I reported about two years ago made them stop building Mesa with static libstdc++. And as @scopatz said, if the end user is using |
Think this was resolved a long time ago by moving to Conda compilers. So going to close this out. Though please let us know if that is not the case and can reopen then. Thanks all! :) |
Recently at work I faced an issue with
libstdc++
binary compatibility on Linux and I would like to share as I believe the current toolchain used by conda-forge could bring the same problem or at least some other people trying to build portable binaries may find this useful.The problem
It was identified when running on
CentOS 7
anOpenGL
application built underCentOS 6
.These are the relevant characteristics:
CentOS 6
using-D_GLIBCXX_USE_CXX11_ABI=0
libstdc++.so.6
, but it's only loaded if the system library is olderdlopen
to load llvmpipe driverllvmpipe
driver links tollvm
libstdc++
(from gcc 4.8.5)This combination resulted on a
free(): invalid pointer
crash as described on this bug reportThe cause of this is that the static member
std::string::_Rep::_S_empty_rep_storage
is defined both onllvm
and thelibstdc++
shipped by the application and therefore there are two different objects on memory._S_empty_rep_storage
is used to represent an empty string, so when trying to dispose a string the library checks if the string is a_S_empty_rep_storage
. But in this case the empty string was the_S_empty_rep_storage
defined byllvm
, while the code was comparing it to the_S_empty_rep_storage
defined on the shipped libstdc++ resulting on a static member being freed.STB_GNU_UNIQUE
To solve exactly this problem STB_GNU_UNIQUE symbol was invented. Better looking into the symbols of the libraries involved shows that this is really the problem:
The llvm library is defining the stdlib static variables as unique, but the shipped
libstdc++.so
is not:That is why there were two different
_S_empty_rep_storage
on memory. The solution was just to recompilegcc/libstdc++ 5.4.0
making sure the static symbols are defined as unique. This implied in using a more recent binutils when building gcc.conda-forge
I'm still not sure if this affects binaries built by
conda-forge
, but AFAIK thedevtoolset-2
used on the docker image uses the default/usr/lib64/libstdc++.so
(gcc 4.4) plus the newer symbols present on 4.8.5, statically linking them./usr/lib64/libstdc++.so
does not define static variables as unique, so I see two cases where the same problem could happen building something on conda-forge:-static-libstdc++
, which will then statically link the symbols present on/usr/lib64/libstdc++.so
The first situation should be rare, but it is definitely something we should be more careful about. The second situation I intend to test better when I get some spare time.
References
https://bugzilla.redhat.com/show_bug.cgi?id=1417663
https://gcc.gnu.org/ml/gcc-help/2017-04/msg00062.html
https://gcc.gnu.org/ml/gcc-help/2017-05/msg00011.html
https://www.redhat.com/archives/posix-c++-wg/2009-August/msg00002.html
The text was updated successfully, but these errors were encountered: