[Desktop-packages] [Bug 1488254]
(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
std::string hello = "Hello, world!\n";
$ cat bar.cc
#include
#include
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
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1488254]
(In reply to comment #31)
> (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".
The new ABI is used for C++98 as well...
> (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.
No, the "automatic tagging of function return types" was unnecessary. The new
ABI was working perfectly fine with both compilers before that change.
--
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
std::string hello = "Hello, world!\n";
$ cat bar.cc
#include
#include
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
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1488254]
(In reply to comment #27)
> (In reply to comment #26)
> > No. It was implemented in April this year, shortly before the gcc-5 release.
> > I've pointed out compatibility issue immediately:
> > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html
> (...)
> > The were no behavioral changes at all after that patch went in.
>
> In the Linaro thread, Jim points out to the abi_tag patch from 2012. Your
> mention is about "significant changes to attribute abi_tag". I can't see how
> I was wrong.
>
>
> > 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.
>
> This is what most of the documentation, email threads and conversations I
> had seem to point at. If you have a different opinion, than by all means,
> please share your knowledge.
>
> Saying "it has nothing to do with" doesn't explain what it has to do with.
> I'm happy to be proven wrong here, as long as we get all the facts on the
> table. This bug doesn't seem to provide strong facts either.
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".
Before that patch (https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01029.html)
both gcc and clang could use the new ABI without any problem.
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.
--
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
std::string hello = "Hello, world!\n";
$ cat bar.cc
#include
#include
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
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1488254]
(In reply to comment #25)
> 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.
No. It was implemented in April this year, shortly before the gcc-5 release.
I've pointed out compatibility issue immediately:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00153.html
> 2. The feature is poorly documented, and may have changed behaviour until
> recently. I have no evidence of changes, is anyone does, please update.
The were no behavioral changes at all after that patch went in.
> 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.
--
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
std::string hello = "Hello, world!\n";
$ cat bar.cc
#include
#include
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
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
