Clang 3.8 and gcc 5.2 has difference in symbol names

Project Infrastructure LLVM Dev List Archives
#1

Hi All,

I’ve built LLVM 3.8 on POWER with gcc 5.2.1 version for one of our application. This application is built using -std=c++14 support.
Using this particular combination, I’m getting one error where one of the exported symbols from our application (for a function returning std::string which is built by gcc) is different than the one when compiled by clang 3.8.

I also tried to replicate this issue by using a small test application which has a function named GetString() returning std::string. When I compile this file using gcc 5.2, I see symbol name as “_Z9GetStringB5cxx11v” and when I compile the same file using clang++, I get symbol name as “_Z9GetStringv”.

In order to resolve this difference, I tried below things -

  • gcc 5.2 with c++11 support has added this special behavior due to which symbol name contains B5cxx11. Hence, I tried building LLVM/clang with -std=c++14 support. But no luck.
  • Even if I provide -std=c++14 while compiling this source file using clang++, the result remained same.
  • I tried setting -D_GLIBCXX_USE_CXX11_ABI=0 flag while compiling my application using gcc. This approach atleast gave me some success. Symbols generated for my source file after using flag were same as that of clang++ (i.e. without B5cxx11). But later my application failed at linking step for some undefined references - some of the references were of the application itself and a few from dependent libraries. I wanted to know if I would also need to build my dependent libraries using this flag.

I need some guidance here as to how I can build LLVM/clang so that it also generates symbols same as that of gcc5.2. I can’t use any other version of gcc as I’ll need rebuild lot of other dependencies.

Kindly help me.

Thanks,
Nishidha

#2

Please see https://llvm.org/bugs/show_bug.cgi?id=23529

#3

Thanks Yaron. I’ve seen this thread earlier. I also wanted to know when will LLVM have a fix for this as mentioned in the thread, it is pending for review. Will the fix be available for LLVM 3.8 or we’ll have to take the latest LLVM?
Also, if I downgrade gcc to 4.9, will LLVM 3.8 work perfectly ?

Thanks,
Nishidha

graycol.gifYaron Keren —05/04/2016 06:31:56 PM—Please see https://llvm.org/bugs/show_bug.cgi?id=23529 2016-05-04 15:52 GMT+03:00 Nishidha Panpaliya

#4

Will the fix be available for LLVM 3.8 or we'll have to take the latest
LLVM?

That depends on its status and the consensus during the 3.8.1 release.

If the patches are good, not affecting anything else and they implement the
feature fully, we'll put it up for consideration.

If every one agrees that it should go into 3.8.1, even being a massive ABI
change and against the rules, then we'll back-port and validate.

But, by how fast it's going, it's even likely that it won't be completely
solved for 3.9.0. :frowning:

Also, if I downgrade gcc to 4.9, will LLVM 3.8 work perfectly ?

Unless you also downgrade your C++ library, it won't work. The problem here
is not GCC, but libstdc++.

cheers,
--renato