← Back to team overview

desktop-packages team mailing list archive

[Bug 1488254]

 

Following up on the Linaro Toolchain list[1], I found out a few facts:

1. This feature was implemented in GCC and libstdc++ in 2012, after
discussions on the cauldron with distro representatives.

2. The feature is poorly documented, and may have changed behaviour
until recently. I have no evidence of changes, is anyone does, please
update.

3. The problem only started because distros have chosen GCC 5 as their
default compilers for the current releases, which defaults to C++11.

4. The fact that GCC developers didn't liaise with Clang developers is a
shame, but understandable. The real issue here is the fact that distro
representatives took an executive decision to change the object layout
of core C++ classes in libstdc++ and to change the ABI without worrying
about other compilers.

If they has asked Clang folks about the ABI change, (and they did, see
this thread), they would have known that the ABI behaviour was poorly
documented and a moving target (as they did, look at this bug), and
should have taken the decision to mitigate the problems.

In this case, I'd expect distro folks to be the middle-men between GCC
and Clang and to make sure that both compilers work well on their new
releases. If you look at this bug and all of those that were marked as
duplicate, you'll see that both Debian and RedHat based distros knew
that Clang still didn't have the feature they needed and why.

True, we could have been more informative and made explicit every detail
on why it was hard to know what to implement, but as middle-men, I
expected distros to be more pro-active towards unification and less pro-
active towards changing the ABI.

[1] https://lists.linaro.org/pipermail/linaro-
toolchain/2016-January/005457.html

-- 
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