[LLVMdev] initializer does not match global variable type.

[Anderson, Todd A]

>> Maybe I wasn't
>> clear.  The "g++" is ordinary vanilla g++, not llvm-g++.  Are there
>> any versioning issues with regular g++ compiling llvm2cpp generated
>> C++ files?  
>
>This could be the weak link. llvm2cpp is a relatively new and fairly
>untested addition to the llvm toolsuite. Its purposes are more for
>instruction and example generation than for use in compiling. It is
>entirely possible that llvm2cpp is not generating *exactly* the 
>C++ code necessary to recreate your module. This is especially true
>since your source language is Objective-C and that has never been tried
>with llvm2cpp.

Hmmm.  When I was trying to compile this stuff, I remember that at one
point I got an error relating to a function return ...Basictype rather
than ...Kindtype.  The prototype and the real implementation of the
function had different return types.  I changed the real implementation
to match the prototype and everything compiled.   I wonder if this is
somehow affecting the code that llvm2cpp is creating.

>> llvm2cpp came from the llvm tarball.  My g++ was 4.1.1.  The LLVM
>> libs are from the llvm tarball I believe and the objc library is
>> probably the gcc 4.1.1 one.  What other information would help?
>
>Well, what are you trying to accomplish?

I am tinkering with a language, call it "foo", that is similar to
C++ and we were looking at the possibility of creating a llvm2foo.
We want to support objective-c so we were looking at a path:
obj-c => ... => foo.

>> >>> cfrontend-g++ -o bar.bc bar.m
>> >>> llvm2cpp -o bar.cpp bar.bc
>> >>> g++ -c bar.o bar.cpp
>> >>> ld -o bar bar.o -l objc -l LLVMCore -l LLVMSupport -l LLVMSystem
>> >>> ./bar
>
>Are you just trying to get your bar.m program to run? If so, there's a
>route that doesn't involve llvm2cpp:

I've gotten bar.m to run the "normal" way, i.e., "g++ bar.m".