docker-alpine: Alpine libs not compatible with Java 8

Trying to install oracle JDK 8 and I get this error when run:

. /opt/jdk/bin/java -version /bin/ash: /opt/jdk/bin/java: : not found /bin/ash: /opt/jdk/bin/java: : not found @@@@@@@?@@@@ |?@@DDP?td??@?@1Q?t/lib64/ld-linux-x86-64.so.2GNU GNU?t?)N?ݓ??;r?Z???h nonexistent directory /bin/ash: /opt/jdk/bin/java: line 1: ELF: not found /bin/ash: /opt/jdk/bin/java: ?: not found /bin/ash: /opt/jdk/bin/java: line 3: ?: not found /bin/ash: /opt/jdk/bin/java: syntax error: unexpected end of file (expecting “)”)

The ldd command give the result:

ldd /opt/jdk/bin/java
    /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libjli.so => /opt/jdk/bin/../lib/amd64/jli/libjli.so (0x7f8da07e0000)
    libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
    libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f8da09f8000)
Error relocating /opt/jdk/bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found

What could be done?

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Reactions: 5
  • Comments: 136 (49 by maintainers)

Commits related to this issue

Most upvoted comments

…Docker itself might be considered as not a production ready solution.

Well, that’s very true! 😃

I hope alpine considers officially supporting oracle java in the future.

Once again. Oracle JDK is a proprietary product, they don’t provide source-code of all their modifications to OpenJDK and build system, just binaries. These binaries are build against glibc (GNU C Library). Alpine Linux doesn’t use glibc, it’s based on (much better) musl libc.

Glibc and musl libc are (partially) incompatible (mainly because glibc doesn’t comply with POSIX standards). Therefore software built against glibc may not work on musl libc without recompiling. This is the case of Oracle JDK. Because it’s a proprietary product, we can’t recompile it and there’s nothing we can do about it!

libc is a very base system library, it’s not yet another library you can simply install along with others. Adding support for glibc would basically mean supporting another platform. The cost of this is too high. Also it doesn’t make much sense; Alpine with glibc would not be Alpine anymore! Alpine’s “motto” is: small, simply and secure. You can’t get this with glibc.

Ask Oracle for musl support, they have the key, not Alpine.

You can’t safely and stably install an Oracle JDK on a system with musl libc and it needs to be prominently admitted that such is the case instead of pushing these hacks forward.

You’re also wrong about OracleJDK vs OpenJDK, there are significant differences and they do impact performance and stability. They can exist side by side with glibc provided to them, but the whole point of this exercise is that OracleJDK isn’t compiled against musl libc.

I have contacted the Oracle support and I got the following statements regarding libmusl and the JRE / JDK:

The Oracle Java product organization maintains a limited number of “standard” configurations for Java and there is no plan to build it with the libmusl library. When customers request Java for other configurations, the Oracle Java product organization - Java Engineering Services (JES) - can create, certify and maintain custom version of Java for alternative O/S, special libraries, embedded architectures, older code bases, etc.

A typical engagement with JES would be: JES proposes a fixed-price engagement to do a “port” which is to deliver a certified version of Java on a non-standard platform. JES could also offer 12-months of Maintenance (renewable each year) to fix bugs and give updates.

Just as musl and glibc ‘should’ be interchangeable, the reality is that OpenJDK and Oracle JDK also ‘should’ be interchangeable.

This is very different situation. glibc and musl libc are different software, they both implements POSIX standards, but the code base is totally different. Oracle JDK is just a branded distribution of OpenJDK, the source code base is the same. Also you can easily install more JDKs side by side on one system, but not two libc.

So basically, if you need OracleJDK, you’ll have to use one of the “standard” configurations for Java (eg use windows or oracle linux). If you need something else you’ll have to hire JES.

In the first place, the issue of OracleJDK not working on Alpine is not the issue of Alpine, but the issue of OracleJDK, which is not compiled for musl libc. Thus, if you wish to get things fixed properly, you have to ask Oracle to support musl libc. Meanwhile, everything that we implement here would be a hack either you install glibc from a repository or wget + apk add <files>. Nevertheless, there are two images that should save almost everybody from headaches: frolvlad/alpine-oraclejdk8 (167MB Oracle JDK image) and develar/java (117MB Oracle JRE image). I try to keep my image up-to-date, and I use it in production in my current projects.

Looking at this, it seems that it wasn’t a Java bug, but glibc hack side effect…

@andyshinn You know better about glibc packages. Do you think it is possible that this nsswitch.conf issue is introduced because of them?

@andyshinn UPD: I didn’t need to bring libz.so from ubuntu, but needed to create symlinks: /usr/lib/libc.musl-x86_64.so.1 pointing at /lib/libc.musl-x86_64.so.1 /usr/lib/libz.so.1 pointing at /lib/libz.so.1

Note: For some reason, LD_LIBRARY_PATH doesn’t work in this case for me.

We have a new glibc package if anyone would like to test this out. You can grab the package at https://circle-artifacts.com/gh/andyshinn/alpine-pkg-glibc/6/artifacts/0/home/ubuntu/alpine-pkg-glibc/packages/x86_64/glibc-2.21-r2.apk and install with apk add --allow-untrusted glibc-2.21-r2.apk. This should allow Oracle Java 8 and other glibc x86_64 native binaries to run on Alpine.