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

[Brian Cain via llvm-dev]

On Wed, Mar 22, 2017 at 10:29 AM, Martin J. O'Riordan via llvm-dev <
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/20170323/5dcb1c23/attachment.html>