desktop-packages team mailing list archive

[Lighttpd-2 <1488254@xxxxxxxxxxxxxxxxxx>]

(In reply to comment #34)
> (In reply to comment #33)
> > I really see no option in this; if the return type is tagged, the tag must be
> > present in the signature somehow, or you can never mix different ABIs in the
> > same binary.
> 
> This was probably already discussed, but if you mangle the return type, how
> can you mix this with previous mangling?
> [...]

I said *tagged* return types, i.e. only those which need to break the
ABI anyway.

> And how different from this did GCC implement their mangling and why is it
> worse?

(Also see my previous post)

- if the return (or variable) type is tagged, tag the function (or variable)
- if the tag is already present in other places in the name (say
  function arguments), it is not added
- depending on the context it might not be added at all (nested functions,
  special symbols). very complex rules.
- for more details see my patch (has some docs), if you want to see some
  examples: http://files.stbuehler.de/test-itanium-mangle.html

(In reply to comment #35)
> I really think that implementing the full gcc abi-tag support is not 
> feasible for Clang. 
> So I would recommend to focus on compatibility with the single (new) ABI
> alone.
> 
> Distros that use the new ABI have recompiled all their C++ libraries,
> so there isn't much need for the dual ABI anyway.

The new ABI requires the full gcc abi-tag support to be compatible with
gcc. If you compile everything with clang and disable dual ABI support
you can get away with less, but what is the point? Just use the clang
libc++ instead, which requires no changes.

> (After all the ABI tags are just a tool to help with the transition.)

And a tool to help with future transitions (and in any other c++
libraries too). A nice tool, I might add, just not very well designed.

> But this is all that's needed. Just change the mangling of the affected
> return (and variable) types and you're set.

Please take a look at the examples (above), which need to work to make
clang compatible with gcc.
There is no shortcut.

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