desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #157675
[Bug 1488254]
(In reply to comment #26)
> (In reply to comment #25)
> > 3. The problem only started because distros have chosen GCC 5 as their
> > default compilers for the current releases, which defaults to C++11.
>
> No gcc-5 doesn't default to C++11 and the issue here has nothing to do with
> C++98 vs. C++11.
>
> Please try to get the facts strait, before posting long misleading replies.
It is related to C++11; afaik one of the reasons to break the ABI was to
become C++11 standard compliant; also the new classes are tagged
"cxx11".
(In reply to comment #28)
> The incompatibility was introduced by gcc's "automatic tagging of functions
> and variables with tagged types where the tags are not already reflected in
> the mangled name".
>
> Now every library function with e.g a std::string return type causes linker
> errors.
>
> To solve this issue, Clang only would have to implement the return type ABI
> tagging. All other ABI tags are irrelevant AFAIK.
"Only" sounds like it would be easy and obvious. Sadly, this is not a
trivial problem.
The change was necessary to support dual-abi in one binary; you need to
be able to distinguish different ABIs in the return type.
(In reply to comment #29)
> The relevant issue is whether libstdc++'s _GLIBCXX_USE_CXX11_ABI is enabled
> by default, see
> <https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html>.
Yes. All distributions have the choice not to enable it by default in
the first place.
(In reply to comment #30)
> (In reply to comment #28)
> > To solve this issue, Clang only would have to implement the return type ABI
> > tagging. All other ABI tags are irrelevant AFAIK.
>
> If I read correctly, one of the emails says this is only temporary, and
> wouldn't show in the final object, since C++ doesn't distinguish return
> types, that's most useful.
No, it is not temporary.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to llvm-toolchain-3.6 in Ubuntu.
https://bugs.launchpad.net/bugs/1488254
Title:
clang++ no longer ABI-compatible with g++
Status in LLVM:
Confirmed
Status in llvm-toolchain-3.6 package in Ubuntu:
Confirmed
Bug description:
$ cat foo.cc
#include <string>
std::string hello = "Hello, world!\n";
$ cat bar.cc
#include <string>
#include <iostream>
extern std::string hello;
int main() {
std::cout << hello;
return 0;
}
$ g++ -c foo.cc && g++ foo.o bar.cc && ./a.out
Hello, world!
$ clang++ -c foo.cc && clang++ foo.o bar.cc && ./a.out
Hello, world!
$ g++ -c foo.cc && clang++ foo.o bar.cc && ./a.out
/tmp/bar-34fb23.o: In function `main':
bar.cc:(.text+0x14): undefined reference to `hello'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
$ clang++ -c foo.cc && g++ foo.o bar.cc && ./a.out
/tmp/ccqU38Mh.o: In function `main':
bar.cc:(.text+0x5): undefined reference to `hello[abi:cxx11]'
collect2: error: ld returned 1 exit status
In practice, this means that many programs using C++ libraries other
than libstdc++ fail to compile with clang++. For example, mosh fails
with undefined references to
google::protobuf::internal::empty_string_,
google::protobuf::MessageLite::InitializationErrorString() const, and
google::protobuf::MessageLite::SerializeAsString() const.
To manage notifications about this bug go to:
https://bugs.launchpad.net/llvm/+bug/1488254/+subscriptions
References