Porting OpenJ9 to RISC-V

ChengJin01 commented 5 years ago

We determined to port a complete runtime environment including OpenJDK11 + OpenJ9 + OMR (without JIT) to the RISC-V development board (e.g. HiFive Unleashed with Linux support / please refer to https://www.sifive.com/boards/hifive-unleashed for details) to get it work on the board.

According to the explanation of RISC-V cross-compilers at https://www.lowrisc.org/docs/untether-v0.2/riscv_compile/, the JDK /JRE is supposed to be executed with Linux support in the user mode as the JVM /application is multiple-threaded.

Overall, there are a bunch of prerequisites before compiling OpenJ9:

the Freedom E SDK (https://github.com/sifive/freedom-e-sdk) + openOCD ready for use (already offered on the website at https://www.sifive.com)
compile a cross compiler with glibc support: e.g. riscv-unknown-linux-gnu-gcc based on the instructions at https://github.com/riscv/riscv-gnu-toolchain; if OK, check whether it works good with simple test.
probably need the Yocto build system (https://www.yoctoproject.org/ or https://github.com/riscv/meta-riscv) to build everything including a Linux/RISC-V kernel (https://github.com/riscv/riscv-linux), a root file system image, a bootloader, a toolchain, QEMU, etc.
(to be added if anything else)

Considering the complexity & unexpected challenges during the porting, the project will be split into at least 4 sub-tasks as follows to be accomplished to achieve our goal:

compile a build without JIT on Linux (changed all request config/setting to get it work) to ensure it works good as expected; if everything goes well, all changes will be added to the compilation with riscv-unknown-linux-gnu-gcc.
import the FFI code (libffi) for RISC-V support to OpenJ9 (https://github.com/libffi/libffi/tree/master/src/riscv / need to open an Eclipse CQ for that)
figure out whether we need to modify the related config/setting in the Freedom E SDK and how to integrate them into the config/setting in OpenJDK11 + OpenJ9 + OMR to ensure the build is compiled with riscv-unknown-linux-gnu-gcc.
might need to run via an Emulator (e.g. QEMU) on the host to ensure it works before uploading.
figure out how to flash/upload the compiled build & the Linux port to the development board to get it executed/tested.
(to be added if anything else)

The issue at #11136 was created separately to track the progress of OpenJ9 JIT on RISC-V. Another issue at https://github.com/eclipse-openj9/openj9/issues/12699 for the CI pipline environment setup.

FYI: @DanHeidinga , @pshipton, @tajila

mstoodle commented 5 years ago

@shingarov you might be interested in this one :)

ChengJin01 commented 5 years ago

Currently, I already finished the following jobs:

verified the HiFive1 32bit board with simple tests (e.g. compile/upload a program with the Freedom E SDK to the board) to understand how it works.
compiled a 32 bit Linux cross compiler (riscv32-unknown-linux-gnu-gcc) but there might be some issue with the compiler. Still working on that.

ChengJin01 commented 5 years ago

@pshipton , I am wondering whether we should disable the shared classes on the resource-limited board (only 128M flash memory available for use, which includes the Linux port/utilities, the Java build, user applications, etc) as the shared cache is set to 300M by default.

In addition, we might need to disable some modules/unnecessary stuffs in code to get things easy to go on the board.

JasonFengJ9 commented 5 years ago

@ChengJin01 jlink can generate java.base only JRE (no other modules).

ChengJin01 commented 5 years ago

Probably need to disable these modules in config/setting in the OpenJDK before compiling the build with riscv32 as there might be no way to run jink on the compiled build (all executables are already in the RISC-V format) on the host machine.

pshipton commented 5 years ago

@ChengJin01 When the available disk space is small, the default shared cache size should be 64MB. However I can guess this still might be too big. We do want to ensure shared classes is working, and could set an even smaller size for this platform, like 16M or even 4M just for test purposes. @hangshao0

pshipton commented 5 years ago

Actually, this is 32-bit, so the default shared cache size should be 16MB already. The 300MB default size is for 64-bit only.

ChengJin01 commented 5 years ago

I doubled-check the document on HiFive1(32bit FE310), it is actually 16MB off-chip flash memory (128Mbit). So the shared cache still needs to be reduced if possible.

In addition, according to the technical Spec on FE310 at https://docs.platformio.org/en/latest/frameworks/freedom-e-sdk.html https://github.com/RIOT-OS/RIOT/wiki/Board:-HiFive1

HiFive1 Features & Specifications
Microcontroller: SiFive Freedom E310 (FE310)
SiFive E31 RISC-V Core
Architecture: 32-bit RV32IMAC
...
Memory: 16 KB Instruction Cache, 16 KB Data Scratchpad <--- 16KB RAM
...
Flash Memory: 128 Mbit Off-Chip (ISSI SPI Flash)

and the discussion of Linux port on HiFive1 at https://forums.sifive.com/t/is-there-a-linux-distribution-that-can-run-on-hifive1/658/5, it seems the 32bit FE310 chip holds a very tiny RAM (16KB) which is far from enough to support the Linux kernel.

Given that porting OS kernel to the board is not our focus, there might be two options for us to move forward: 1) choose 64bit HiFive FU540 Unleashed (Linux-capable, multi-core / https://www.sifive.com/boards/hifive-unleashed) to support Linux on chip for JVM. 2) consider to use a RTOS (must support multi-threading / e.g. RTLinux, Zephyr, Apache Mynewt, etc) with RISC-V 32bit support. It is still unclear whether we can make it work in this way and how many code/libraries in OpenJ9 need to be adjusted to accommodate the RTOS.

@DanHeidinga

DanHeidinga commented 5 years ago

1) Can the HiFive1 boards be extended with additional RAM & disk? 2) Is there an emulator for the RISC-V that we can use while working to procure more suitable boards?

3) We want to target Linux with this work as it simplifies the rest of the porting effort.

mstoodle commented 5 years ago

Surely supporting the shared classes cache could be considered on the "nice to have" list rather than in the initial set of priority activities for a new platform bring up?

Is there an existing new platform bring-up (ordered) checklist? If not, could we start creating one as part of this effort?

ChengJin01 commented 5 years ago

@DanHeidinga ,

Can the HiFive1 boards be extended with additional RAM & disk?

There is no public doc/Spec shows it can do that but we can bring this question to their forum at https://forums.sifive.com. (already raised the question at https://forums.sifive.com/t/extending-the-hifive1-board-with-additional-ram-disk/2155)

Is there an emulator for the RISC-V that we can use while working to procure more suitable boards?

The typical emulator is QEMU (https://github.com/riscv/riscv-qemu) both with RISC-V (RV64G, RV32G) Emulation Support. It will be used to boot the Linux/shell so as to run the JVM after compilation.

We want to target Linux with this work as it simplifies the rest of the porting effort.

In this case, there might be not too many options in term of development boards except the 64bit HiFive FU540 Unleashed board.

Technically, most of work will be finished (compilation, emulation, etc) before uploading everything to the board which should be the final steps to verify whether it really works on the RISC-V chip/hardware. So it might be not that urgent for the moment to decide which board to use as long as we get our build work on RISC-V via emulator.

ChengJin01 commented 5 years ago

Already talked to @mstoodle on slack, we can create a high-level/generic porting guideline not specific to any platform with our porting experiences on RISC-V, which helps people to understand the basic/key steps to follow when porting OpenJ9 to a new platform.

hangshao0 commented 5 years ago

we can create a high-level/generic porting guideline not specific to any platform with our porting experiences on RISC-V, which helps people to understand the basic/key steps to follow when porting OpenJ9 to a new platform

@knn-k has some recent experience porting OpenJ9 onto Aarch64. He might be helpful regarding the porting guideline.

knn-k commented 5 years ago

If it is without the JIT, you can take a look at these PRs to begin with for what I have done with AArch64 VM build:

3502, #3559, #4087, #4333, #4350, #4487, #4696

ChengJin01 commented 5 years ago

@knn-k , many thanks for your links of changsets. I believe we will get started with at least something similar (with RISC-V instruction sets) except Docker-related stuff as we need to run it directly on hardware/board.

knn-k commented 5 years ago

AArch64 VM uses the Docker image for cross-compilation on x86-64 Linux. I would appreciate any feedback from your RISC-V effort.

ChengJin01 commented 5 years ago

[1] The response as to extending the 32bit board with external RAM/disk as follows: https://forums.sifive.com/t/extending-the-hifive1-board-with-additional-ram-disk/2155/3

A while ago, one suggestion to extend the amount of memory was to connect a 
SPI RAM to the board’s SPI GPIO pins. It’s slower than direct RAM but depending 
on the use-case it might be enough:
...
Though to be honest it might very well be that your application
 (if it requires “far more than 16MB”) is too much for this board.

So it seems extending the hardware this way is tricky and it is hard to say whether the 32bit board can really support that.

[2] I went over the Spec document for the 64bit board at https://sifive.cdn.prismic.io/sifive%2Ffa3a584a-a02f-4fda-b758-a2def05f49f9_hifive-unleashed-getting-started-guide-v1p1.pdf,

HiFive Unleashed is a Linux development platform for SiFive’s Freedom U540 SoC, 
the world’s first 4+1 64-bit multi-core Linux-capable RISC-V SoC. 
The HiFive Unleashed has 8GB DDR4, 32MB QuadSPI Flash, a Gigabit Ethernet port, 
and a MicroSD card slot (can be used to boot the linux image) for more external storage.

If it is the mainstream hardware setup on the 64bit board, there should be no limitation on RAM/disk for Linux kernel + JVM with this board, whether it comes to RAM or the share cache.

[3] There are 3 options for the cross-compilation & EQMU emulation: 1) manually compile all related artifacts including cross-compiler + Linux kernel + Boot Loader +an customized shell environment, etc from the source, for which https://github.com/michaeljclark/busybear-linux already integrated everything we need in the cross-compilation. but it is unclear whether the generated boot image & Boot Loader works good on the real hardware.

2) https://buildroot.org/ Buildroot includes everything required for cross-compilation but it needs manual choice for a bunch of configurations.

3) https://github.com/riscv/meta-riscv Yoctco provides a one-stop integration environment for cross-compilation pretty much without any manual intervention except a simple choice for the image type, coming with a full-featured Linux environment for RISC-V-based cross-development. The only drawback is it mostly ends up with over xGB Linux image which seems huge in size to us (it might not be a big problem if booting from the SD-card).

I will go with the option 1) to compile everything including EQMU, which is the fastest & straightforward way we can do to solve all problems on our side before moving forward to the on-board/hardware verification.

If there is any special configuration/setting required in the boot process on the hardware which can't be done via 1), I will go back to check whether 2) or 3) works that way.

ChengJin01 commented 5 years ago

Already created the RISC-V cross compiler on 64bit:

/opt/riscv_gnu_toolchain_64bit/bin$ ./riscv64-unknown-linux-gnu-gcc  --version
riscv64-unknown-linux-gnu-gcc (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Will keep compiling other related artifacts.

alistair23 commented 5 years ago

Hello,

I would like to add some comments.

First off I am a large contributor to meta-riscv and the Yocto/OpenEmbedded world in general. Please let me know what you need and I will help wherever I can. The less time you all spend on getting Linux running the more time you can spend on porting Java :)

Please do not spend time on the HiFive1 board OR 32-bit RISC-V. The HiFive1 board is very small, it's basically a RISC-V version of an Arduino. RISC-V 32-bit support is still lacking so you should start with 64-bit support. You can develop for 64-bit RISC-V on either the HiFive Unleashed or QEMU. QEMU has great RISC-V support and you should be able to do all your development on QEMU. If you want help running QEMU please let me know, I am also a QEMU maintainer and am happy to help here as well.

I think meta-riscv is the best option from above to use (option [3]). It's extremely powerful and you won't have any issues of size in either QEMU or on the HiFive Unleased. Buildroot is also an option (as a maintainer here as well I can help if required). I would not recommend to build it all yourself, you will end up wasting a lot of time building toolchains, Linux and related packages.

alistair23 commented 5 years ago

If you want to do native work you can also just run Fedora on QEMU and dnf install all the packages you need.

Either way, let me know how to help and I will do what I can

alistair23 commented 5 years ago

Something else worth noting is that most of the repos on the github riscv account are out of date. For Linux, GNU tools and QEMU you should use mainline not the riscv forks.

ChengJin01 commented 5 years ago

@alistair23 , many thanks for your suggestion & recommandation. Actually I already finished compiling everything on 64bit including QEMU with option 1) (just a minor issue with ntpd which can be ignored for now). We will move forward to the next step to compile our code if everything goes fine.

The problem with option [3] is it will end up with a huge size of linux image which I already tried but stopped it when it exceeded 9GB (What we need is a normal Linux kernel with decent shell support, so there is no need to integrate everything for Linux). With option 1, we are able to customize the size for use (e.g. 1GB or less if necessary).

I won't go for option 2) or 3) for now unless there is something unexpected when compiling our code.

alistair23 commented 5 years ago

Great, I'm glad you got it working!

I'm not sure how you eneded up with a 9GB image, my full OpenEmbeded desktop images with debug symbols and self hosted toolchains aren't that big.

Either way can you keep me updated with the progress? Also let me know if there is anything that I can do to help.

ChengJin01 commented 5 years ago

@alistair23 , I didn't try other options except bitbake core-image-full-cmdline guided at https://github.com/riscv/meta-riscv and the whole folder there kept increasing to over 9GB (eventually screwed up my VM due to out-of-space).

Basically the compilation of our code will be done with the 64bit cross-compiler outside of QEMU and mount the whole build inside to get executed in there. So we definitely need your support from QEMU perspective. My guess is there will be a bunch of problems with QEMU once we're done compiling our code to get it work, specifically in debugging in QEMU if it crashes or something similar happens.

Just keep subscribed in this issue and you will be informed with what is going on in our project.

alistair23 commented 5 years ago

Ah, the temporary files can get big. That makes more sense.

Great! I am subscribed to this issue so I will keep and eye on things and help where I can. QEMU is very stable and the RISC-V support is also mature. If possible it would be best to build it from the master branch in mainline QEMU. Otherwise the 3.1+ releases are in good shape.

Good luck with this. Java is one of the few missing pieces for RISC-V so it will be great when you get it running :)

ChengJin01 commented 5 years ago

Working on other crash issue on Windows. Will get back to this once we address that problem.

ChengJin01 commented 5 years ago

I am currently compiling a build without JIT components (excluded from OpenJ9 & OMR) on a Fyre Linux machine and then on my Ubuntu VM to eliminate any compilation error with JIT excluded.

If it works good, the next step is to get the risc-v toolchain introduced in the configure/setting to see what happens (temporarily ignore the spec setting & code specific to riscv and just ensure it picks up the correct cross-compiler/tools in the process of compilation)

ChengJin01 commented 5 years ago

Just finished the compilation on Linux without JIT on my Ubuntu VM

oot@jincheng-VirtualBox:...# jdk/bin/java -version
JVMJ9VM011W Unable to load j9jit29: /home/jincheng/RISC_V_OPENJ9/openj9-openjdk-jdk11/build/linux-x86_64-normal-server-release/images/jdk/lib/compressedrefs/libj9jit29.so: cannot open shared object file: No such file or directory
openjdk version "11.0.3-internal" 2019-04-16
OpenJDK Runtime Environment (build 11.0.3-internal+0-adhoc.root.openj9-openjdk-jdk11)
Eclipse OpenJ9 VM (build master-32fb64b, JRE 11 Linux amd64-64-Bit
 Compressed References 20190401_000000 (JIT disabled, AOT disabled)
OpenJ9   - 32fb64b
OMR      - 5ceecf1
JCL      - ff6f49a based on jdk-11.0.3+2)

and will get started to figure out how to modify the config/setting for RISC-V on OpenJDK11 side.

ChengJin01 commented 5 years ago

The main reasons that our build needs to be compiled outside of QEMU/Linux are 1) Except the cross-compilers (gcc/g++ for riscv), a bunch of tools & commands (e.g. m4, etc) required in compiling the JDK are not entirely provided in riscv-gnu-toolchain & QEMU/Linux and there is no need to do so as they are offered on the Linux-based building platform. 2) The boot JDK (which is not compiled with the riscv cross-compiler) can't be executed in QEMU/Linux and must be used outside during the whole compilation.

So the first problem we encountered in the configuration check of JDK is the lack of X11 support in riscv-gnu-toolchain (it is required for libawt in JDK)

checking for X... no
configure: error: Could not find X11 libraries.

configure:58129: /opt/riscv_gnu_toolchain_64bit/bin/riscv64-unknown-linux-gnu-g++ -E  conftest.cpp
conftest.cpp:21:10: fatal error: X11/Xlib.h: No such file or directory
 #include <X11/Xlib.h>
          ^~~~~~~~~~~~
compilation terminated.
...

https://github.com/riscv/riscv-gnu-toolchain/tree/master/linux-headers/include
/riscv-gnu-toolchain/linux-headers/include# ls -l
total 48
drwxr-xr-x  2 root root  4096 Apr  2 12:15 asm
drwxr-xr-x  2 root root  4096 Apr  2 12:15 asm-generic
drwxr-xr-x  2 root root  4096 Apr  2 12:15 drm
drwxr-xr-x 28 root root 16384 Apr  2 21:10 linux
drwxr-xr-x  2 root root    56 Apr  2 12:15 misc
drwxr-xr-x  2 root root   135 Apr  2 12:15 mtd
drwxr-xr-x  3 root root  4096 Apr  2 12:15 rdma
drwxr-xr-x  3 root root   145 Apr  2 12:15 scsi
drwxr-xr-x  2 root root   321 Apr  2 12:15 sound
drwxr-xr-x  2 root root    89 Apr  2 12:15 video
drwxr-xr-x  2 root root   110 Apr  2 12:15 xen
<----------------------------------------------------- X11 is missing in riscv-gnu-toolchain

the X11 libraries should be part of riscv-gnu-toolchain otherwise the cross-compiler/linker fails to locate them during the compilation (the library will be used in QEMU/So we can't use the same one on the building platform).

There are two options to deal with the problem: 1) figure out how to integrate X11 (https://github.com/mirror/libX11) to riscv-gnu-toolchain, which might take a while to get things work. 2) skip X11 in configure for the moment and disable all X11 related code later in the compilation to see how far we can push forward. If it works out, we will get back to address X11 once we finish compiling the JDK build.

ChengJin01 commented 5 years ago

@alistair23 , do you know the basic steps to build X11 to riscv-gnu-toolchain?

alistair23 commented 5 years ago

the X11 libraries should be part of riscv-gnu-toolchain otherwise the cross-compiler/linker fails to locate them during the compilation (the library will be used in QEMU/So we can't use the same one on the building platform).

The problem isn't that you don't have X11 in the toolchain, it's that you don't have the X11 libraries installed for the guest. My advice would be to use Yocto/OpenEmbedded to build a rootFS. Continuing to build these manually will be more and more of a pain.

The other option is to use RISC-V Fedora, where you probably can dnf install the libraries.

alistair23 commented 5 years ago

1. Except the cross-compilers (gcc/g++ for riscv), a bunch of tools & commands (e.g. m4, etc) required in compiling the JDK are not entirely provided in riscv-gnu-toolchain & QEMU/Linux and there is no need to do so as they are offered on the Linux-based building platform.

This doesn't sound right. This sounds like you haven't installed the required tools onto the guest image. Almost all packages that run on x86 will run on RISC-V, about 90% of the Fedora/Debian packages are being cross compiled. My colleague just checked and m4 can be installed in Fedora with a simple dnf install and it's available as a RISC-V target package in OpenEmbedded.

If you would like to continue cross compiling the packages for RISC-V then I strongly recommend using meta-riscv and OpenEmbedded. It will handle all of these complexities for you as cross compiling an entire distro is a lot of work. If you want to do native compile/development then Fedora (or Debian) is the way to go.

alistair23 commented 5 years ago

2. The boot JDK (which is not compiled with the riscv cross-compiler) can't be executed in QEMU/Linux  and must be used outside during the whole compilation.

Does this mean that it is impossible to natively compile JDK on a non-x86 architecture?

ChengJin01 commented 5 years ago

Does this mean that it is impossible to natively compile JDK on a non-x86 architecture?

Technically yes, the compilation of JDK is done with cross-compiler, macro preprocessor, other tools as well as the boot JDK (used for java source) which is only compiled on the host /can't be used/executed in QEMU.

alistair23 commented 5 years ago

Does this mean that it is impossible to natively compile JDK on a non-x86 architecture?

Technically yes, the compilation of JDK is done with cross-compiler, macro preprocessor, other tools as well as the boot JDK which is only compiled on the host /can't be used in QEMU.

The compiler, macro pre-processor and standard build tools will all work on a non-x86 native compile.

So boot JDK is x86 only?

When you say can't be used in QEMU, do you mean QEMU specifically or just that it can't be built on non-x86 architectures?

ChengJin01 commented 5 years ago

So boot JDK is x86 only?

Not really, we always need a boot JDK (already compiled) for the compilation. Basically, compiling a JDK always involves a boot JDK (only x86 in our case) which is already ready for use; otherwise there is no need to compile outside of QEMU if everything including the boot JDK is ready for use inside.

alistair23 commented 5 years ago

So boot JDK is x86 only?

Not really, we always need a boot JDK (already compiled) for the compilation. Basically, compiling a JDK always involves a boot JDK (only x86 in our case) which is already ready for use; otherwise there is no need to compile outside of QEMU if everything including the boot JDK is ready for use inside.

Ah, so boot JDK is a bootstrapper that allows you to compile. In this case boot JDK is already and only compiled for x86 so you need to do a x86 host cross compile.

Thanks for clarifying what boot JDK is.

In which case a native Fedora style compile won't work for you. I still recommend OpenEmbedded then.

ChengJin01 commented 5 years ago

In which case a native Fedora style compile won't work for you. I still recommend OpenEmbedded then.

At this point, does the cross-compiler can locate the correct X11 libraries offered from OpenEmbedded (the total compilation must be outside of QEMU) ?

alistair23 commented 5 years ago

OpenEmbedded will allow you to build the entire distro on your host machine (x86).

OpenEmbedded will build the X11 libraries for you and will link with them.

ChengJin01 commented 5 years ago

@alistair23, many thanks for your suggestion. I will try to see whether OpenEmbedded works for us in such case. Let me know whether there is anything that needs to be aware of in installing/building OpenEmbedded (links, guides, etc)

alistair23 commented 5 years ago

If you want I can have a go at it. Is there some sort of Java that can be cross compiled today?

I would recommend just following the docs in meta-riscv. There is also the Yoe distro (https://github.com/YoeDistro/yoe-distro) that seems easy to use, although I don't use it.

ChengJin01 commented 5 years ago

Is there some sort of Java that can be cross compiled today?

Might exist but not available in the public as far as I know. You could try Hotspot OpenJDK to see how it works. Actually, that's what we are currently doing here.

alistair23 commented 5 years ago

I figured that, I just meant is there maybe some WIP that I could test the build process with or maybe config options to disable the JIT and interpreter. I misread what you posted above and thought you had something running on RISC-V.

Either way, let me know if there is anything else you need

ChengJin01 commented 5 years ago

@alistair23 , I already followed the instructions at https://github.com/riscv/meta-riscv to build the image on one of our internal Ubuntu VM.

bitbake core-image-full-cmdline
runqemu qemux86 nographic
...
root@qemuriscv64:/# uname -a
Linux qemuriscv64 5.0.3-yocto-standard #1 SMP PREEMPT Wed Apr 3 23:31:29 UTC 2019 riscv64 riscv64 riscv64 GNU/Linux

It seems this is pretty much the same one as I already done before to build the EQMU environment (I didn't find any compiler/toolchain pre-installed in the EQMU), which is only used to launch the target JDK instead of compiling the JDK source. Even though the toolchain is installed in there, there is no way to launch boot JDK inside as it is compiled on Linux/X86_64.

In our case, the cross-compiler (riscv64-gnu-gcc/g++) must work with the boot JDK(already compiled on Linux/X86_64) to compile the native and java code for the target JDK (run on riscv-64). That being said above, the cross-compiler/toolchain must work on the same platform (Linux/X86_64) as the boot JDK (outside of EQMU), which is the requirement of the target JDK configuration/setting.

ChengJin01 commented 5 years ago

I also checked the result from an online Fedora/RISC-V enviroment (also without X11 headers at /usr/include) at https://rwmj.wordpress.com/2018/09/13/run-fedora-risc-v-with-x11-gui-in-your-browser/ , which ended up with the same error in such case.

It seems a bunch of native headers in OpenJDK require X11 libraries to be compiled, which means we can't be simply ignore X11 during compilation. Might still need to figure out how to get X11 work in riscv-gnu-toolchain or other way around.

DanHeidinga commented 5 years ago

Does configuring with --with-x=no work around the issue?

ChengJin01 commented 5 years ago

It doesn't help and will ends up with the following error:

checking how to link with libstdc++... static
configure: error: It is not possible to disable the use of X11. Remove the --without-x option.
configure exiting with result code 1

as already explained at /riscv_openj9-openjdk-jdk11/make/autoconf/lib-x11.m4

    if test "x${with_x}" = xno; then
      AC_MSG_ERROR([It is not possible to disable the use of X11. Remove the --without-x option.])
    fi

and /riscv_openj9-openjdk-jdk11/make/autoconf/libraries.m4

AC_DEFUN_ONCE([LIB_DETERMINE_DEPENDENCIES],
[
  # Check if X11 is needed
  if test "x$OPENJDK_TARGET_OS" = xwindows || test "x$OPENJDK_TARGET_OS" = xmacosx; then
    # No X11 support on windows or macosx
    NEEDS_LIB_X11=false
  else
    # All other instances need X11, even if building headless only, libawt still
    # needs X11 headers.  <---------------------------
    NEEDS_LIB_X11=true
  fi

ChengJin01 commented 5 years ago

I managed to hack the the script in configure to disable the X11 libraries and will keep checking the remaining errors in config.

alistair23 commented 5 years ago

It seems this is pretty much the same one as I already done before to build the EQMU environment (I didn't find any compiler/toolchain pre-installed in the EQMU), which is only used to launch the target JDK instead of compiling the JDK source. Even though the toolchain is installed in there, there is no way to launch boot JDK inside as it is compiled on Linux/X86_64.

Yep, OpenEmbedded doesn't include the toolchain in the guest image by default. To install it just edit your IMAGE_FEATURES variable in your conf/local.conf file.

Something like this will give you development and debug packages for all installed packages and it will install the tools required to build and debug natively.

IMAGE_FEATURES += "debug-tweaks dev-pkgs dbg-pkgs tools-sdk tools-debug"

I don't understand why you need native RISC-V compiler tools though. I thought because you need the boot strap boot JDK which only runs on x86 you need to do a cross compile?

alistair23 commented 5 years ago

I also checked the result from an online Fedora/RISC-V enviroment (also without X11 headers at /usr/include) at https://rwmj.wordpress.com/2018/09/13/run-fedora-risc-v-with-x11-gui-in-your-browser/

I don't understand this. I have been saying you can use Fedora and you can run it in directly in QEMU. I thought that isn't an option because you need to cross compile on x86 due to the boot JDK boot strapper?

eclipse-openj9 / openj9

Porting OpenJ9 to RISC-V #5058

3502, #3559, #4087, #4333, #4350, #4487, #4696