Ubuntu LLVM packages incompatible with clang built projects?

Hi folks,

Not sure if this is the right mailing list target, but I’m trying out the new LLVM 7.0 packages found at http://apt.llvm.org by porting over an existing LLVM 6.0 project of ours to the new version. In doing so, I found that the executable always segfaulted at the same spot with no explanation:

0x0000000000fefe33 in llvm::RegisterTargetMachinellvm::X86TargetMachine::Allocator(llvm::Target const&, llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::TargetOptions const&, llvm::Optional<llvm::R
eloc::Model>, llvm::Optionalllvm::CodeModel::Model, llvm::CodeGenOpt::Level, bool) ()

This happens if I build my project and link it against LLVM 7.0 with either clang++ 6.1 or clang++ 7.0. This does not happen if I build my project with g++ 8.

I have also confirmed that building LLVM 7.0 with clang++ and then using that private build of the libraries fixes the issue.

To summarize, it seems that there’s an ABI incompatibility introduced somewhere, which means LLVM 7.0 compiled with gcc can only be used by other projects also built with gcc. Is this something that’s being investigated and to be resolved as a fix in 7.1? If not, is there any official release note that’s remarking on this incompatibility?


Hi Kern,

We also had issues with mixing GCC/Clang builds when testing the 7.0 release branch.

My colleague submitted a patch that fixed the issue for us:

  • I no longer have a copy of the error we were seeing to see if it was the same, but the fix is to llvm::OptionalStorage and your error message involves llvm::Optional. The patch removes a GCC specific ifdef, and hopefully fixes the issue that made that necessary in the first place, but we never really knew how the GCC miscompilation was expressed.

It would be interesting to know whether this resolves your issue, but regardless we should give the patch a prod.

Alastair Murray.

Just be aware that those ifdefs were recommitted and reverted several times, so I’m not sure what the state is.

Trunk still has the different gcc and clang versions.

What's worse, the 7.0.0 release has them too :frowning: I completely missed
this and we can't fix it for 7.0.1 since that would also be an ABI

Alastair, if you noticed this during the release testing, did you
surface it anywhere?

Hi Hans,

No we didn't surface this beyond submitting the patch. As Reid pointed out these same ifdefs have already been removed/re-added a few times in 2018, so while the patch works for us it isn't suitable for back-porting until it has been merged to trunk and the build-bots have given it a try.

It did not occur to me that it would not be possible to apply the change to 7.0.1, but your point make sense.

We didn't notice this during release-testing in the sense of building an LLVM package, but rather when linking some configurations of our own code against an LLVM built from the release branch.

Alastair Murray.

Trunk still has the different gcc and clang versions.

What's worse, the 7.0.0 release has them too :frowning: I completely missed
this and we can't fix it for 7.0.1 since that would also be an ABI

Is this something we could fix by adding a symbol alias to the
linker script for libLLVM.so?


I can confirm that Alastair’s patch works for me. Steps taken:

  1. git checkout https://git.llvm.org/git/llvm.git/ @ 65ce2e56889 (release_70)
  2. configure with “CC=gcc-8 CXX=g+±8 cmake -GNinja -DCMAKE_BUILD_TYPE=RelWithDebInfo … -DLLVM_TOOL_CLANG_BUILD=OFF -DCMAKE_INSTALL_PREFIX=$HOME/code/llvm-install/7/gcc/RelWithDebInfo”
  3. build with “ninja install”
  4. build my own project and link against new custom llvm build
  5. run offending executable and notice SEGFAULT
  6. apply patch (below)
  7. step #2, but with install prefix changed to $HOME/code/llvm-install/7/gcc-patch/RelWithDebInfo
  8. step #3 and #4
  9. run offending executable and notice successful run

If this patch can’t make it in for LLVM 7.0.1, could it make 7.1? If so, what kind of timeline would you expect?


Ping. Is there any update on what the plan is for addressing this issue?

Ben, what do you think about just reverting to what we had before
r322838? It seems we still don't know how to do this in a way that
doesn't break with (old) GCC, and I'm guessing it's not really worth
the trouble that the optimization brings?

As for if we can do anything for 7.0.1, I don't know.