building LLVM/Clang on Windows 7 x64 using MinGW/MSYS

Clang Frontend
#1

Hello,

I have been trying to build the SVN trunk head revision of LLVM/Clang in order to use the latest static analyzer. I have reinstalled the latest MinGW/MSYS with GCC 4.8.1 and updated all components. I am using the Cmake build tools to build LLVM/Clang. I have CMake 2.8.10.2 installed. Cmake generates build files for MSYS Makefiles.

When I run make everything seems to go well until it tries to link liblibclang (at about 91% of the build I believe). This link fails with an APPCRASH error being caught by Windows (ld.exe has stopped working…). The problem details reported by Windows 7 are:

Problem signature:

Problem Event Name: APPCRASH

Application Name: ld.exe

Application Version: 0.0.0.0

Application Timestamp: 5222b8a9

Fault Module Name: ld.exe

Fault Module Version: 0.0.0.0

Fault Module Timestamp: 5222b8a9

Exception Code: c0000005

Exception Offset: 00034d98

OS Version: 6.1.7601.2.1.0.256.48

Locale ID: 4105

Additional Information 1: 7151

Additional Information 2: 7151a73bf833b82e616f341fb6bc2635

Additional Information 3: 7b98

Additional Information 4: 7b98c89d9ec70855f86cad8f1de194c2

When I select “close the program” I get the following error report:

collect2.exe: error: ld returned 5 exit status

Which causes the build to fail. I have attached a copy of the verbose output of the link command as out2.txt.

This appears to be an access violation problem with ld.exe from MInGW. Has anyone built the head of LLVM/Clang using the latest MinGW tools? Is this a known problem with the current MinGW? Is there a work around to get this link to succeed?

Since I had successfully built an older version of LLVM/Clang with and older version of MinGW (4.7.2 if my memory is correct), I tried to build the last release version, release 3.3, of LLVM/Clang using the same MinGW 4.8.1 and Cmake. This time I get a compiler error attached as error.txt while building clangBasic.

The name _stat64i32 is defined in the file stat.h included from MinGW/include/sys/stat.h. It looks like FileManager.h is declaring these functions before stat.h is included, and then FileManager.cpp is defining them after stat.h is included which causes the stat type to be replaced by _stat64i32 by macro definitions. I don’t see how this is supposed to work. Again is this a known problem with release 3.3 and MInGW?

I noticed that the signature of this function has been changed in head revision to use a type FileData instead of the struct stat directly, so perhaps this problem has been addressed already.

Any insight anyone can provide will be greatly appreciated.

Thanks.

out2.txt (9.27 KB)

error.txt (5.26 KB)

#2

I’d try switching MingW distribution as it’s very easy to do.

If you’re now using http://www.mingw.org/ try http://sourceforge.net/projects/mingwbuilds/ and vice verse. These are different distributions with different patches and different binaries.
For instance ld.exe in the former is 9MB and in the later 944K.

Yaron

#3

Hi,

I also had some problems with building llvm+clang on MinGW 4.8.1 + MSYS. Another thing was that linker did require ~3GB memory to complete on x64.

Here in the readme I have listed steps and linked versions of MinGW and MSYS to use for being able to compile llvm + clang on Windows 7.

https://github.com/KhronosGroup/webcl-validator#building-with-windows-mingw–msys

Good luck!

Best regards, Mikael Lepistö

#4

3GB is too close for comfort for the 32 bit linker.
G M reports success with the 64 bit toolchain so maybe it’s actually required with current versions.

Are you using the 32-bit toolchain or 64-bit toolchain of mingw-builds?

Yaron

#5

Hi Yaron,

I am using the 32 bit MinGW tools, so that may be the problem. I would have hoped for an “out of memory” error from the linker rather than an access violation, but I know many programmers assume there will never be a memory problem on today’s machines.

I will have to try the 64 bit version Mikael linked to, to see if the 32 bit linker is actually running out of memory address space.

Thanks to you and Mikael for the tips.

Dennis Cote

#6

I tried building with the MinGW64 compiler and got a different link error at 64% of the build:

Linking CXX executable …/…/bin/lli.exe

…/…/lib/libLLVMExecutionEngine.a(RTDyldMemoryManager.cpp.obj):RTDyldMemoryManager.cpp:(.text+0x8f): undefined reference to `__register_frame’

collect2.exe: error: ld returned 1 exit status

tools/lli/CMakeFiles/lli.dir/build.make:198: recipe for target `bin/lli.exe’ failed

make[2]: *** [bin/lli.exe] Error 1

CMakeFiles/Makefile2:7475: recipe for target `tools/lli/CMakeFiles/lli.dir/all’ failed

make[1]: *** [tools/lli/CMakeFiles/lli.dir/all] Error 2

Makefile:136: recipe for target `all’ failed

make: *** [all] Error 2

So I went back and tried the 32 bit tools again. I got the same failure, but I noticed that ld.exe was only using 1.97 GB of ram when it crashed, so I’m not sure the problem is an address space issue.

I will be busy with moving for a few days, but any other ideas are welcome.

Dennis Cote

#7

"Dennis Cote" <DennisC@harding.ca> writes:

I tried building with the MinGW64 compiler and got a different link
error at 64% of the build:

Linking CXX executable ../../bin/lli.exe

../../lib/libLLVMExecutionEngine.a(RTDyldMemoryManager.cpp.obj):RTDyldMemoryManager.cpp:(.text+0x8f):
undefined reference to `__register_frame'

collect2.exe: error: ld returned 1 exit status

This sounds familiar. I think that you are mixing object files or
libraries compiled with different exception handling methods
(SJLJ/Dwarf2)

#8

That sounds familiar, are you using MinGW64 4.8.1? I had to take older version of it to make successful build. With MinGW64 4.6.3, MSYS rev 12 and cmake, I didn’t get ‘__register_frame’ error.

BR, Mikael Lepistö