[cfe-dev] [RFC] Possible ABI break for libc++ built with -fno-rtti and -D_LIBCPP_BUILD_STATIC
Martin J. O'Riordan via cfe-dev
cfe-dev at lists.llvm.org
Sun May 7 06:50:01 PDT 2017
Hi Eric,
In the email I sent on the 27th April (“[LibC++] Bug in implementation of 'std::shared_ptr'”), the problem I was seeing was:
o LibC++ library built with -DLIBCXX_ENABLE_RTTI=ON and -D_LIBCPP_BUILD_STATIC.
o User code compiled with ‘-fno-rtti -D_LIBCPP_BUILD_STATIC’.
Having ‘_LIBCPP_BUILD_STATIC’ defined by both the library builder and the library user was where it broke. I removed ‘-D_LIBCPP_BUILD_STATIC’ from the user and it worked. But I wasn’t building the static library with RTTI disabled because it is stated as an unsupported configuration.
So are you advising that with the proposed fix, that I should revert to defining ‘_LIBCPP_BUILD_STATIC’ as the user?
Thanks,
MartinO
From: Eric Fiselier [mailto:eric at efcs.ca]
Sent: 04 May 2017 00:43
To: clang developer list <cfe-dev at lists.llvm.org>
Cc: Marshall Clow <mclow.lists at gmail.com>; Duncan P. N. Exon Smith <dexonsmith at apple.com>; Ed Maste <emaste at freebsd.org>; Martin J. O'Riordan <martin.oriordan at movidius.com>; Anton Korobeynikov <anton at korobeynikov.info>
Subject: [RFC] Possible ABI break for libc++ built with -fno-rtti and -D_LIBCPP_BUILD_STATIC
Hi All,
Libc++ currently has an ABI incompatibility when built as a static library with no RTTI. Specifically some std::shared_ptr internals have different vtable layouts in this configuration.
I would like to fix this by making the vtable definition consistent across all configurations, but that requires breaking the ABI of a very rare configuration of libc++. I suspect all users of this configuration can take the ABI break immediately, but I would like to confirm this before proceeding.
The configuration in question is a static libc++ library built with -DLIBCXX_ENABLE_RTTI=OFF and -D_LIBCPP_BUILD_STATIC,
Is anybody using this configuration and can't take an ABI break?
Note that `_LIBCPP_BUILD_STATIC` must be manually defined by the user at both when building and using libc++, and it is not supported by the CMake build system. This should mean that almost nobody is defining it.
The proposed changes can be found here: https://reviews.llvm.org/D32838
/Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170507/55c2352e/attachment.html>
More information about the cfe-dev
mailing list