assert problem embedding llvm libs in linux - stuck

Project Infrastructure LLVM Dev List Archives
1

Hi,

I have a shared library that makes use of LLVM/clang to add JIT capabilities to a front-end interface in Lua. This shared library is used within an executable application. This all works and builds fine on OSX, but I'm having trouble replicating it for Linux. The build process goes fine, with no changes to the library code, however I'm receiving a SIGABRT caused by an assert when run:

/include/llvm/Support/CommandLine.h:483: void llvm::cl::parser<DataType>::addLiteralOption(const char*, const DT&, const char*) [with DT = const llvm::TargetMachineRegistryEntry*, DataType = const llvm::TargetMachineRegistryEntry*]: Assertion `findOption(Name) == Values.size() && "Option already exists!"' failed.

I'm not so familiar with the internals of LLVM nor standard practices for development on Linux, so I wondered if there is an experienced developer on the list who can spot the problem immediately...? I've spent a few hours trying to figure this out, and I'm stuck. I'm not even sure why commandline options (llvm::cl::parser) are being called, since I'm embedding the libraries within an application.

More info:

Using llvm/clang revision 68132, Ubuntu 8.10.
Built llvm/clang using --enable-optimized --enable-pic

Code using LLVM/clang is built into a shared library (.so) linked to the LLVM/clang .a files and the .o files for Interpreter, ExecutionEngine, JIT, X86AsmPrinter and X86CodeGen.
This shared library is then linked into an executable, which also links with the LLVM/clang .a and .o files. Maybe this isn't the right way to do it, but it was the only way I could get it to build.

I'd post the code, but it would be incredibly lengthy.

Thanks

Graham

2

Sure, you can't have two copies of the libraries that can see each other. Put them into one shared library used by both sides, if they are meant to be shared, or separate them out completely, if they are not meant to be shared. If you separate them out, run nm, and see if there is _any_ routine that comes from llvm (or clang) in the thing that has clang in it on the link line.

3

And if you see any, remove them with a linker export file....

4

Thanks, I thought that might be the issue... on OSX I had them linked only to the shared library, but on Linux I was having unresolved symbols when the libs were not linked to both shared lib and application. Need to get more familiar with Linux development...

Anyway, thanks again