[NativeAOT-LLVM] compiling for Linux

[yowl]

I'm trying to fix up the scripts so that compiling the repo on Linux is possible. Most seems to be compiling ok, but I have a problem compiling the browser wasm clrjit:

 [ 76%] Preprocessing /home/scott/github/runtimelab/src/coreclr/jit/ClrJit.Llvm.exports. Outputting to /home/scott/github/runtimelab/artifacts/obj/coreclr/Linux.x64.Debug/jit/ClrJit.Llvm.exports.def
  [ 76%] Building CXX object jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/cmake_pch.hxx.pch
  [ 76%] Building C object jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/__/version.c.o
  In file included from <built-in>:1:
  In file included from /home/scott/github/runtimelab/artifacts/obj/coreclr/Linux.x64.Debug/jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/cmake_pch.hxx:5:
  In file included from /home/scott/github/runtimelab/src/coreclr/jit/jitpch.h:4:
  In file included from /home/scott/github/runtimelab/src/coreclr/pal/inc/rt/cpp/stdint.h:4:
  In file included from /home/scott/github/runtimelab/src/coreclr/pal/inc/rt/palrt.h:136:
  /home/scott/github/runtimelab/src/coreclr/pal/inc/pal.h:47:10: fatal error: 'errno.h' file not found
  #include <errno.h>
           ^~~~~~~~~
  1 error generated.
  make[3]: *** [jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/build.make:81: jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/cmake_pch.hxx.pch] Error 1
  make[2]: *** [CMakeFiles/Makefile2:3734: jit/CMakeFiles/clrjit_browser_wasm32_x64.dir/all] Error 2
  make[1]: *** [CMakeFiles/Makefile2:1727: CMakeFiles/wasmjit.dir/rule] Error 2
  make: *** [Makefile:182: wasmjit] Error 2
  ~/github/runtimelab/src/coreclr
  Failed to build "CoreCLR component".

As you can see I have no errno.h, should that be installed be some dependency, or is it bringing it in incorrectly?

[jkotas]

runtimelab/src/coreclr/pal/inc/pal.h:47:10: fatal error: 'errno.h'

This should come from the Linux system include paths. The coreclr build system plays tricks when the system include paths are used and when they are not used that have to be in sync with whether PAL_STDCPP_COMPAT is defined or not.

I think the problem is that PAL_STDCPP_COMPAT is defined for the JIT now, but the system include path are not used for the JIT.

[yowl]

Thanks, I see

runtimelab/src/coreclr/CMakeLists.txt

Lines 204 to 208 in 335bf0a

	# Include the dummy c++ include files
	include_directories("pal/inc/rt/cpp")
	# This prevents inclusion of standard C compiler headers
	add_compile_options(-nostdinc)

Which looks like the lines I want to not execute for building the llvm clrjit, but is that possible? I tried just

  message("replace usr/include?")
  if (NOT CLR_CMAKE_BUILD_LLVM_JIT)
    message("replace usr/include? Yes")
    # Include the dummy c++ include files
    include_directories("pal/inc/rt/cpp")

    # This prevents inclusion of standard C compiler headers
    add_compile_options(-nostdinc)
  endif(NOT CLR_CMAKE_BUILD_LLVM_JIT)

But it excludes the standard headers in places where I think I still want the dummy headers e.g.

[ 14%] Building CXX object nativeresources/CMakeFiles/nativeresourcestring.dir/resourcestring.cpp.o
  In file included from /home/scott/github/runtimelab/src/coreclr/nativeresources/resourcestring.cpp:6:
  In file included from /home/scott/github/runtimelab/src/coreclr/inc/utilcode.h:13:
  In file included from /home/scott/github/runtimelab/src/coreclr/inc/crtwrap.h:14:
  In file included from /home/scott/github/runtimelab/src/coreclr/pal/inc/rt/windows.h:12:
  In file included from /home/scott/github/runtimelab/src/coreclr/pal/inc/rt/palrt.h:136:
  In file included from /home/scott/github/runtimelab/src/coreclr/pal/inc/pal.h:73:
  /home/scott/github/runtimelab/src/coreclr/pal/inc/pal_mstypes.h:221:16: error: typedef redefinition with different types ('char' vs '__int8_t' (aka 'signed char'))
  typedef __int8 int8_t;
                 ^

[jkotas]

pal_mstypes.h:221:16: error: typedef redefinition with different types ('char' vs '__int8_t' (aka 'signed char')) typedef __int8 int8_t;

This error means that PAL_STDCPP_COMPAT is not defined, but standard headers are getting included. I think you either need to define PAL_STDCPP_COMPAT here (and fix any subsequent build breaks that it may produce), or you need to stop including the standard headers here.

I think defining PAL_STDCPP_COMPAT in more places is generally the better way to go. Ideally, we would define it everywhere: dotnet/runtime#37310 .

[yowl]

Thanks, I'll try the first suggestion. Just so I don't start in the wrong place, the files in src/coreclr/palrt , should they be required with PAL_STDCPP_COMPAT ?

[jkotas]

If the component that you are switching to compile with PAL_STDCPP_COMPAT depends on any of the methods implemented in this directory, I think you may need to switch this directory to compile with PAL_STDCPP_COMPAT too.

[yowl]

Thanks, I got as far as something compiling, but it sigsegvs on start up, maybe something to do with a missing PAL_RegisterModule symbol. I don't know if that should exist, or if it shouldn't even be calling it. I tried turning on COREHOST_TRACE=4, hoping to see

runtimelab/src/coreclr/pal/src/loader/module.cpp

Line 1629 in 335bf0a

TRACE("Calling DllMain (%p) for module %S\n",

But I don't see that message, so bit lost as to what is trying to call PAL_RegisterModule

[yowl]

Maybe I misunderstood TRACE and I need to use COMPlus_CreateDumpDiagnostics and createdump. Will try that.

[yowl]

Nope, export PAL_DBG_CHANNELS="+all.all" didn't produce any stderr output either. but if module.cpp is not in libcoreclr.so maybe that's no surprise. Stumped.

[yowl]

I understand I need a trace enabled verison of coreclr for the tracing to work, so i'll try dotnet-symbol instead

[yowl]

I'm going to close this for now as realistically I'm not going to have time to move it forward. https://github.com/yowl/runtimelab/tree/llvm-linux is where I got to.