Port OMR to QNX Neutrino

[dschaefer]

Now that OpenJ9 is, well, open, I'd like to take a crack at porting to QNX's Neutrino RTOS. Neutrino is POSIX complaint for the most part and has a priority based scheduler so I'm hoping it's not a gigantic amount of work, but I'd like to start plugging away at it.

So far, I've needed a number of additions to the CMake files. I'll create PRs for them once I can get reasonable build output.

Any other tips and tricks would be appreciated.

[mgaudet]

We'd love any and all feedback you can give, especially for using CMake in a cross-compilation scenario.

I expect there will be a number of roadblocks you'll encounter, as the CMake support is experimental, but we'd love to hear everything.

[dschaefer]

Will do, I'm a big fan of CMake especially for it's multi-toolchain support. So far so good, just needed to add handling for the QNX OS, toolchain, etc. Also reminded me to add PROCESSOR to my toolchain file :).

[charliegracie]

That is great news @dschaefer. Depending on the CPU architecture you are using the compiler support may not be completed in CMake. If the CMake compiler support is not complete on your platform (cmake should error early on) You can set the following 3 flags to off OMR_JIT, OMR_JITBUILDER and OMR_TEST_COMPILER in the cmake cache file you are using (or via the command line). Depending on the platform I am hoping this is pretty straight forward to the core working. If you see any inefficiencies in our CMake support, as we are just learning, let us know and we will do our best to clean them up.

[dschaefer]

OK, now that I have Ninja building things, the first thing I've run into is that it tries to run tracegen. Unfortunately, tracegen was built for QNX. To support cross, I need it to build for my build host. I'm actually not sure how to do this in CMake, but it's a common pattern that I'm sure someone has figured out.

[charliegracie]

@dnakamura and @rwy0717 please help with this as I believe you are aware of the solution.

[rwy7]

We baked in a way to import the tools from a different build, but it hasn't been attempted in a while.

1. You'll need a native build of OMR. Tools are on by default, but feel free to disable the GC and Compiler.

   cd omr
   mkdir build_native && cd build_native
   cmake -GNinja ..
   ninja

   This will create an omr/build_native/tools/ImportTools.cmake file, which can be used to import the native tools into a cross compiled build.

2. Disable building the tools for your QNX build, and import the tools from your native build. If you try to import tools AND leave them enabled, cmake will complain.

   # assuming you are at omr/build_qnx/
   cmake -DOMR_TOOLS=OFF -DOMR_TOOLS_IMPORTFILE=../build_native/tools/ImportTools.cmake ..

3. Build it:

   ninja

[dschaefer]

Cool. Makes sense. I'll give that a try. Thanks!

[dnakamura]

@rwy0717 you forgot -GNinja in the second cmake invocation.

Also you can ommit -GNinja and then s/ninja/make/

[dschaefer]

Sweet. Got legit compile errors now. That's where the fun (i.e. real port) begins. Thanks!

[rwy7]

Oh, I should mention, we've got a little guide on cross-compiling here.

[dschaefer]

Just noticed that when I started writing a little guide for QNX next to it :).

BTW, I have an MSYS2/MINGW64 environment set up and use that by default but ran into build errors when building the native bits. Not sure that's supported so I switched to my VS2017 shell and that worked fine.

[dnakamura]

Oh yeah, MSYS/MINGW is completely untested, and probably very broken. The cmake side may be broken, but more importantly the codebase is pretty broken in that regard. Since historically speaking it has only ever been built with a limited number of configurations it often makes bad assumptions