Open cpcloud opened 11 years ago
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"
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.
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).
Has there been any joy on this front? LLVM 3.2 still seems to cause grief with the TargetData.h -> DataLayout.h move.
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 "
_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
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.
I have updated the README in this commit https://github.com/llvmpy/llvmpy/commit/ff515528383aefad97ceb5d755d21138bd2d0b53
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.
The important part of the error from gcc is as follows:
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.