[Cygwin] onsistant error building LLVM

Project Infrastructure LLVM Dev List Archives
1

Consistant error building LLVM on Cygwin from CVS :-

make[2]: Entering directory /usr/build/llvm/tools/llc' llvm[2]: Compiling llc.cpp for Debug build llvm[2]: Linking Debug executable llc /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function _GLOBAL__D__ZN7
6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_DD38501517X
86TargetLowering14LowerArgumentsERN4llvm8FunctionERNS1_12SelectionDAGE’:
/usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to X86C ompilationCallback2' /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x305f2):/usr/src/llvm/lib/Target/X86/ X86ISelPattern.cpp:73: undefined reference to _X86CompilationCallback’
/usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30601):/usr/src/llvm/lib/Target/X86/
X86ISelPattern.cpp:73: undefined reference to _X86CompilationCallback' collect2: ld returned 1 exit status make[2]: *** [/usr/build/llvm/Debug/bin/llc.exe] Error 1 make[2]: Leaving directory /usr/build/llvm/tools/llc’
make[1]: *** [llc/.makeall] Error 2
make[1]: Leaving directory `/usr/build/llvm/tools’
make: *** [all] Error 1

Don’t know what is causing it.

Aaron

2

If you look in X86JITInfo.cpp, you'll find CompilationCallback. I'm not
sure about CompilationCallback2. In any event, the code is conditionally
compiled and that might be tripping things up on Cygwin.

Reid.

3

I have done another test and it seems to be my cygwin development environment :frowning:

I cannot seem to reproduce my previous Cygwin environment on which we got LLVM and the frontend tested.

Oh well I'll try again. It just seem such a long development cycle to test. When I am ment to be testing my instillation instructions !

Try, try again...

Aaron

4

X86CompilationCallback2 is also defined in X86JITInfo.cpp. One is a thin assembler wrapper around the other. No matter how things are conditionally compiled, both functions will be present. Is X86JITInfo.cpp itself being compiled?

Reid Spencer wrote:

5

I ran into the same kinds of issues when I was working on Cygwin. I had
meant to complete it but the disk died on that machine (probably from
doing nightly builds every night .. it was just a laptop).

Anyway, thanks for your efforts to get Cygwin straightened out. This
will help many people, I suspect.

Reid.

6

Also, this error:

/usr/src/llvm/lib/Target/X86/X86ISelPattern.cpp:73: undefined reference to `X86CompilationCallback2'

doesn't make sense. X86CompilationCallback2 is not visible outside of X86JITInfo.cpp, and line 73 of X86ISelPattern.cpp is in the middle of a comment block.

7

Perhaps Aaron has some local edits, possibly with a cut and paste error?

8

No edits, its from the CVS.

I would not spend any time worrying about this.

I'll try another Cygwin instillation and build. The Cygwin instillation seems not to be very good, have had quite a few problems with it :frowning:

Aaron

9

Here's the instructions as I have them so far :-

        http://angray.members.beeb.net/llvm/MakingLLVM.html

I was wondering whether you could look them over to see if I am doing something obviously wrong.

Thanks,

Aaron

10

Sure, but not right now. I need to go out for a bit. I'll look at them
tonight.

Reid.

11

When one moves an instruction from one BasicBlock to another, the
instruction continues to believe that its parent is the original BasicBlock.
This is very undesirable. Is there a way to set the parent or a way to move
the instruction such that the parent is updated correctly?

12

Currently, my way around this was to go into Instruction.h and make
setParent() public. I hope there is a better way?

13

Currently, my way around this was to go into Instruction.h and make
setParent() public. I hope there is a better way?

You shouldn't be modifying the API like this ...

When one moves an instruction from one BasicBlock to another, the
instruction continues to believe that its parent is the original
BasicBlock. This is very undesirable. Is there a way to set the
parent or a way to move the instruction such that the parent is
updated correctly?

See LICM::hoist() in lib/Transforms/Scalar/LICM.cpp for an example.

14

Yes, actually I was wrong. It does change the parent, I just haven't gotten
enough sleep :wink: