undefined symbol EnableABIBreakingChecks

Project Infrastructure LLVM Dev List Archives
#1

Hi,

when using the "Debug" build of LLVM 8.0 my application which uses the LLVM builder and MCJIT components fails at startup with:

symbol lookup error: ./main: undefined symbol: _ZN4llvm23EnableABIBreakingChecksE

(unmangled: llvm::EnableABIBreakingChecks)

The application works fine with the "Release" build of LLVM 8.0! (Right now, I need the Debug build for access to dump() ).

The application works also fine with both the Debug or Release build with LLVM 6.0.

Looking for differences regards this variable didn't point me in any direction:

A simple grep over the LLVM source gives the same output for LLVM 6.0 and LLVM 8.0:

include/llvm/Config/abi-breaking.h.cmake:extern int EnableABIBreakingChecks;
include/llvm/Config/abi-breaking.h.cmake:__attribute__((weak, visibility ("hidden"))) int *VerifyEnableABIBreakingChecks = &EnableABIBreakingChecks;
lib/Support/Error.cpp:int EnableABIBreakingChecks;

What am I missing here?

Best,

Frank

#2

Hi Frank,

What am I missing here?

LLVM has some more expensive checking that breaks ABI compatibility
(e.g. by adding extra verification fields to structs). In a
strraightforward world if you linked together .o files compiled with
and without those checks you'd break horribly at runtime.

So LLVM has two symbols, "EnableABIBreakingChecks" and
"DisableABIBreakingChecks" and exactly one of them gets referenced
from every header that would change. This error indicates that some of
your files were compiled with LLVM_ABI_BREAKING_CHECKS and some
without.

The fact that it appears to be a runtime issue (i.e. when you execute
./main) suggests to me that you've got a dynamically linked LLVM and
it's picking up the wrong .so files. But a botched build is also
possible.

Cheers.

Tim.

#3

Thanks, Tim!

The path for the dynamic loader was set to the "Release" build.

Best,

Frank