llvm dev - Mar 2009 - [LLVMdev] assert problem embedding llvm libs in linux - stuck

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

On Mar 31, 2009, at 3:58 PM, Graham Wakefield wrote:
> 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...?
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.

On Mar 31, 2009, at 4:15 PM, Mike Stump wrote:
> 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.
And if you see any, remove them with a linker export file....

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

On Mar 31, 2009, at 4:15 PM, Mike Stump wrote:
> On Mar 31, 2009, at 3:58 PM, Graham Wakefield wrote:
>> 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...?
>
> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev