[llvm-dev] Building LLVM on Linux, executing on Windows 10 Linux Subsystem

Fri Mar 24 02:50:39 PDT 2017

Thanks Brian, these are helpful pointers.

            MartinO

From: Brian Cain [mailto:brian.cain at gmail.com] 
Sent: 24 March 2017 03:04
To: Martin J. O'Riordan <martin.oriordan at movidius.com>
Cc: LLVM Developers <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Building LLVM on Linux, executing on Windows 10 Linux Subsystem

On Wed, Mar 22, 2017 at 10:29 AM, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > wrote:

Our out-of-tree LLVM compiler is configured and built on Linux, but I cannot get it to run under the Windows 10 Linux Subsystem.

When run in this context it reports a crash:

warning: Error disabling address space randomisation: Success

warning: linux_ptrace_test_ret_to_nx: PTRACE_KILL waitpid returned -1: 

Interrupted system call

The above messages are due to a bug in how windows handles ptrace(PTRACE_GETSIGINFO).  I think if you downgrade gdb you might not see this error.  Does it still segfault when you don't run it in the debugger?  Can you do your compile with "-###" and see the "clang -cc1" command and run that one separately?

Program received signal SIGSEGV, Segmentation fault.

0x0000000003b31e1b in __ctype_init ()

(gdb) bt

#0  0x0000000003b31e1b in __ctype_init ()

#1  0x0000000003b2ed4e in __libc_start_main ()

#2  0x00000000004022ad in _start ()

(gdb) list

302

<myPathTo>/llvm/tools/clang/tools/driver/driver.cpp: 

No such file or directory.

(gdb)

However, the Linux version from the LLVM website works perfectly, so it must be something to do with how I am configuring LLVM.  The following are the OS and tool versions I am using:

Would it work any better if you tried building the compiler natively with this unique configuration on WSL?  If it did it might help you isolate the problem.

Also, Microsoft looks like they have a history of reviewing and addressing compatibility bugs just like this one on their GH repo.  

e.g. https://github.com/Microsoft/BashOnWindows/issues/1373

Sometimes it comes down to them not quite supporting a particular critical syscall quite the same way it behaves on linux.

*         CentOS Linux release 7.1.1503 (Core)

*         gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)

*         cmake version 3.5.2

*         GNU Make 3.82

and I am configuring with the following options:

mkdir -p build/linux64

cd build/linux64

cmake -Wno-dev -G “Unix Makefiles” ../../llvm \

"-DCMAKE_BUILD_TYPE:STRING=Debug" \

"-DCMAKE_INSTALL_PREFIX:STRING=$(CLANG_INSTALL_ROOT)/Debug" \

"-DCMAKE_EXE_EXPORTS_C_FLAG:STRING=" \

"-DCMAKE_EXE_EXPORTS_CXX_FLAG:STRING=" \

"-DCMAKE_EXE_LINKER_FLAGS:STRING=-static-libgcc -static-libstdc++ -static" \

-DLLVM_TARGETS_TO_BUILD="OURTARGET" \

-DLLVM_DEFAULT_TARGET_TRIPLE=ourtarget

Only the highlighted options are perhaps unusual as I need to build with statically linked GCC libraries, and the ‘DCMAKE_EXE_EXPORTS’ flags were required to prevent another problem with dynamic libraries, though I have forgotten what this was now.

The resulting compiler works perfectly on Linux, but when I run the same binary in the Windows 10 Linux Subsystem, I get the crash report above.

It's always a good idea to make sure your environment matches when you're comparing two different systems.  "env -i clang++ test_case.cpp" on both can help neutralize any funny business that might creep in.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170324/e444ea19/attachment.html>