desktop-packages team mailing list archive

[Octoploid <1488254@xxxxxxxxxxxxxxxxxx>]

(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > (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.
> > > 
> > > The change was necessary to support dual-abi in one binary; you need to
> > > be able to distinguish different ABIs in the return type.
> > 
> > No, the "automatic tagging of function return types" was unnecessary. The new
> > ABI was working perfectly fine with both compilers before that change.
> 
> As long as you keep the ABIs completely separated it works, yes.
> 
> To get basic dual ABI support you could require manual tagging of all
> functions
> which need tags (like, say, `std::string std::to_string(int)`) - but such
> procedure would be way too much work and error prone.
> 
> Especially if you have third party libraries providing such functions (like
> boost),
> which certainly would not start manual tagging, the linker could let you use
> functions you really must not use.

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.

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

> 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.
> 
> (I would have preferred to simply make tagged return (and variable!) types
> part
> of the name, which would have been straightforward compared to the mess GCC
> implemented: if the tag is already present in certain places, it is not
> added,
> depending on the context it might not be added at all, ...)

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

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