How to install java on arm musl?

[M95D]

I did install Alpine openjdk package, but I'm stuck again with "Exec format error":
https://forums.gentoo.org/viewtopic-t-1169902.html

[pingtoo]

[M95D]

The other topic provides all the information I have, including lscpu, the Gentoo profile I use, CFLAGS I enabled, "file" output for the executable file, and now I just added a readelf output. That's for the cargo executable. The java executable is exactly the same format, but if you insist, here it is:

[pingtoo]

M95D,

Yes, I am aware of your other post, I was just wondering which alpinelinux openjdk package you installed. And where you got the error message because from the other post, it is in the build stage you got the error.

Can you thinking of another program have simular charitistic (another programming language, or something external to Gentoo but you mamange got it working) and try to run a readelf on it. Does it show anything different?

I don't have armv7 box handy. I could try to setup a QEMU but not sure if will able to reproduce this.

From your output, the error should not happen. I am not sure, I will do some more digging.

P.S. Can you share output of lddtree on your java binary?

[M95D]

The binary is from the Alpine packages recommended above. The error appears during the emerge too. I just ran it manually this time because the output is more readable than digging through dozens of lines of emerge log.

lddtree is interesting! There's a significant difference from native-built bash executable:

[eschwartz]

Ah yes, you'll probably have to patch that with the patchelf package. Alpine chose to use an entirely nonstandard soname for the musl libc that is incompatible with any other musl system -- I forgot.

[pingtoo]

M95D,

Do you mind share step by step command you used to get openjdk from alpinelinux installed on your machine?

I think I will need to create a QEMU node to test to see if I can reproduce this problem.

If it still possible can you also share which stage3 file you use. I will try to see if I can found a match or close matched version.

In the mean time I suggest you try to review my suggestion use container or chroot. unless you really want to dig into why. And if you really want to dig in, I will need your kernel config too. so I can rebuild a kernel match yours.

[M95D]

@eschwartz:
Wouldn't a symlink fix that?

I tried patching all executable files from bin/ and all .so files from lib/ and it still doesn't work.

[pingtoo]

M95D,

The patch elf will solve a problem after the executable load into memory and start execution. it will likely generate a "not executation" or "file not found" kind of error message. However your "Exec format error" is a time when kernel loading the binary file it detected something not right.

When I ask for using lddtree to test, is tring to see if the dynamic interrpreter (/lib/ld-musl-armhf.so.1) can detect something that we can follow.

This is partial reason I need to have QEMU to see if I can dig in from the dynamic interpreter and all the other elf/binary tool to see if we find something to compare.

To upload you can try to use app-text/wgetpaste, which put content to public bin dump, without put into a forum post.

[pingtoo]

M95D,

Can you confirm which you use?

[M95D]

Kernel config:
https://marius95.duckdns.org/posted/TkB.config.gz

[pingtoo]

M95D,

Thanks for the information. Now will take some time to construct environment to test.

[M95D]

I made a chroot with the latest stage3 (armv7 hf musl) and the errors are still the same. So, there must be something wrong with the kernel.

[pingtoo]

[fedeliallalinea]

Moved from Portage & Programming to Gentoo on ARM.
_________________
Questions are guaranteed in life; Answers aren't.

[pingtoo]

[M95D]

I don't recognize that file format. How do I use it?

[pingtoo]

[M95D]

I am now emerge-ing docker.

I'm happy to report that go-bootstrap worked!
Isn't rust-stage0 built by the same gentoo servers as go-bootstrap? Why would one work but not the other?

[pingtoo]

[M95D]

I set up a qemu myself.

Add these to kernel config:
CONFIG_SERIAL_AMBA_PL011 (that's the serial driver provided by "-machine virt", but I could find no documentation except some blog post)
CONFIG_SERIAL_AMBA_PL011_CONSOLE
CONFIG_DEBUG_LL (low level debug messages)
CONFIG_DEBUG_LL_UART_PL01X (in LL debug port selection)
DEBUG_UART_PHYS=0x9000000 (physical address 900'0000)
DEBUG_UART_VIRT=0xf8090000 (virtual address F809'0000)
CONFIG_EARLY_PRINTK (to continue showing messages using earlycon until PL011 driver loads)

Add bootargs
earlycon earlyprintk console=ttyAMA0
Do not load a dtb - that's machine-specific. Qemu loads its own, I think.

With this config I got as far as this:

[M95D]

OK. It works!
You only need to add the PL011 UART driver and console.
I was right, the virtual address of that port is wrong and it stops the boot process. Just disable CONFIG_DEBUG_LL and it will boot.
You can still use "earlycon=pl011,0x9000000 earlyprintk" to see early boot messages.

[pingtoo]

[pingtoo]

M95D,

I think I found the mystery. It is due to thumb code flag. (CONFIG_ARM_THUMB). In your kernel config. it is TURN OFF. Alpinelinux gcc by default compile with this flag ON. Gentoo profile does not set this flag. so it is up to user to have it in make.conf

I prepare two rootfs disks for QEMU.

one is alpinelinux mini rootfs: alpine-minirootfs-3.20.2-armv7.tar.gz

one is gentoo stages: stage3-armv7a_hardfp_musl-openrc-20240717T192452Z.tar.xz

using alpinelinux rootfs, the kernel just failed at start /sbin/init, claim it is not unable same error (- which is "Exec format error".

whereas using gentoo rootfs, the kernel start /sbin/init without error.

So I compare Alpinelinux's kernel config and my "vir" config, notice that CONFIG_ARM_THUMB is not set in "vir", enable it and build and run new kernel with Alpinelinux root disk, this time the alpinelinux /sbin/init started. So I believe it is the key to address the "Exec format error".

[M95D]

OMG, that was the last thing I expected to cause problems!
I'll test it right now.

THANKS!!!

PS: Hold on a sec! Shouldn't file and readelf say something if the Alpine's java or rust stage0 were thumb binaries?