Latest release of LLVM breaks llvmpy

[cpcloud]

The important part of the error from gcc is as follows:

llvm/extra.cpp:296:14: error: ‘class llvm::TargetMachine’ has no member named ‘getTargetData’
llvm/extra.cpp:301:32: error: ‘class llvm::TargetMachine’ has no member named ‘getTargetData’
llvm/extra.cpp: In function ‘LLVMOpaqueTargetData* LLVMTargetMachineGetTargetData(LLVMTargetMachineRef)’:

Looks like there's an API call to a member function that no longer exists.

I'm running LLVM 3.2 on a MacBook 4,1 with Arch Linux.

[cdeil]

With Macports llvm-3.2 @3.2-r165785_1+assertions there isn't even a TargetData.h any more:

/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -pipe -O2 -fwrapv -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -D__STDC_CONSTANT_MACROS -D__STDC_LIMIT_MACROS -D_GNU_SOURCE -I/usr/include -I/opt/local/libexec/llvm-3.2/include -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c llvm/extra.cpp -o build/temp.macosx-10.8-x86_64-2.7/llvm/extra.o
llvm/extra.cpp:56:10: fatal error: 'llvm/Target/TargetData.h' file not found
#include "llvm/Target/TargetData.h"

[cpcloud]

Sounds like a path issue for MacPorts. Installing LLVM and Clang from source puts TargetData.h in /usr/local/include/llvm/Target/TargetData.h by default which you may or may not have to add to your system path.

The problem is that getTargetData was removed from the TargetMachine class. TargetMachine now has the method getDataLayout that returns a const instance of DataLayout of which TargetData is a subclass. Using some dynamic_cast magic is the way I fixed it.

I might submit a pull request; I may have fixed this issue.

@cdeil Try locate TargetData.h from your shell to see if the file exists on your system at all (assuming you've created the locate database) just to confirm that it isn't a compiler flag issue.

[cdeil]

I think there's nothing wrong with the Macports llvm-3.2 installation (which basically fetches svn trunk until 3.2 is released). It seems that TargetData.h was moved to DataLayout.h in llvm trunk two weeks ago: https://llvm.org/viewvc/llvm-project?view=rev&sortby=rev&revision=165262 So llvmpy has to be updated to work with llvm trunk (and the future 3.2 release).

[caryan]

Has there been any joy on this front? LLVM 3.2 still seems to cause grief with the TargetData.h -> DataLayout.h move.

[xgnata]

With the current git and llvm-3.2 it does compile but python -c "import llvm; llvm.test()" fails :

Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/dist-packages/llvm/init.py", line 138, in test from llvm.test_llvmpy import run File "/usr/local/lib/python2.7/dist-packages/llvm/test_llvmpy.py", line 21, in from llvm.core import (Module, Type, GlobalVariable, Function, Builder, File "/usr/local/lib/python2.7/dist-packages/llvm/core.py", line 38, in import llvm._core as _core # C wrappers ImportError: /usr/local/lib/python2.7/dist-packages/llvm/_core.so: undefined symbol: _ZTIN4llvm24PassRegistrationListenerE

[sklam]

_ZTIN4llvm24PassRegistrationListenerE is the typeinfo of llvm::PassRegistrationListener. LLVM 3.2 by default disables C++ RTTI, making it "virtually" impossible to inherit any LLVM class. To re-enable RTTI, set environment variable REQUIRES_RTTI=1 when running make. Refer to: http://llvm.org/docs/Packaging.html#c-features

[xgnata]

On 12/31/2012 05:29 PM, Siu Kwan Lam wrote:

_ZTIN4llvm24PassRegistrationListenerE is the typeinfo of llvm::PassRegistrationListener. LLVM 3.2 by default disables C++ RTTI, making it "virtually" impossible to inherit any LLVM class. To re-enable RTTI, set environment variable REQUIRES_RTTI=1 when running |make|. Refer to: http://llvm.org/docs/Packaging.html#c-features

— Reply to this email directly or view it on GitHub https://github.com/llvmpy/llvmpy/issues/29#issuecomment-11779842.

Ok I works with REQUIRES_RTTI=1 It would be good to add something about this issue in the documentation.

[sklam]

I have updated the README in this commit https://github.com/llvmpy/llvmpy/commit/ff515528383aefad97ceb5d755d21138bd2d0b53

[JDWarner]

A Makefile that supports "make clean" might be of use. I ran into this issue and didn't realize it was copying over the old, bad _core.so file from the build directory. Once I fixed that, it's now working - but I had to manually remove the build dir.