desktop-packages team mailing list archive

[Hfinkel <1488254@xxxxxxxxxxxxxxxxxx>]

(In reply to comment #43)
> (In reply to comment #42)
> > OpenMandriva has successfully changed the compiler to clang (3.7.1 for now,
> > will update to 3.8 as it is released), but decided to stick with libstdc++
> > to preserve binary compatibility with other Linux distributions -- users
> > want to run non-open source stuff like steam, and that stuff doesn't get
> > built for OSes that don't have a giant user base.
> 
> If you ship GCC at all, and if that happens to be 5.x, and you happen to
> choose to enable the CXX11 ABI by default, you'll run into the exact same
> problem. Doesn't matter who's on top.
> 
> 
> > OpenMandriva could switch system libraries etc. to libc++, but even then
> > problems would likely arise (e.g. binary-only application links to Qt and
> > expects Qt to be linked to libstdc++ -- the only "fix" would be providing 2
> > different versions of all C++ libraries and even then things would likely
> > break, with e.g. libstdc++-Qt not being able to load style plugins built for
> > libc++-Qt and vice versa, so custom installed widget themes wouldn't work
> > for binary-only applications).
> 
> That, in addition to multilib/multiarch will be a major pain for all
> distros. This really isn't a solution.
> 
> 
> > So yes, there indeed is a use case for building the entire OS with clang but
> > not libc++ until we get to a point where relevant closed source stuff
> > switches to libc++ (or better yet, gets open sourced so people can link it
> > to any STL they like).
> 
> Even if the day Clang and libc++ become the top dog on most Linux
> distributions ever comes, we'll still have to cope with legacy GCC and
> libstdc++ for a good number of decades from then on.
> 
> Coexisting is the only solution for this century.

As a practical manner, we'll never be able to compile all of our
existing code against libc++, unless libc++ decides to implement the
not-insignificant set of libstdc++ extensions (e.g. everything under
__gnu_parallel::, _gnu_cxx::stdio_filebuf)
[https://gcc.gnu.org/onlinedocs/libstdc++/manual/extensions.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