Missing link /lib64/ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2

[wilx]

The package is providing link to /usr/glibc-compat/lib/ld-linux-x86-64.so.2 in /lib but does not provide one in /lib64. This makes current Adoptium Temurin Java to fail to link at start because the /lib64/ld-linux-x86-64.so.2 points at MUSL's /lib/libc.musl-x86_64.so.1 instead.

The failure:

bash-5.1# jre/bin/java
Error relocating /opt/uma/jre/bin/../lib/amd64/jli/libjli.so: __strdup: symbol not found
Error relocating /opt/uma/jre/bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found

The Java JRE binary wants linker from /lib64/ld-linux-x86-64.so.2:

bash-5.1# file /opt/uma/jre/bin/java
/opt/uma/jre/bin/java: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, not stripped

[sgerrand]

@wilx: Would you please provide a minimal example Dockerfile which demonstrates the problem you're experiencing it. Without that I am unable to investigate this matter further.

[dave-voltdb]

I see the same thing. Alpine 3.17, adoptium openjdk jre 11.0.18 for x86_64, plus your alpine glibc 2.35-r1 (or r0).

The JVM won't start - two undefined symbols in libjli.so.

Re-pointing /lib64/ld-linux-x86-64.so.2 to /usr/glibc-compat/lib/ld-linux-x86-64.so.2 fixes the problem, but I don't know what the side effects might be.

"Minimal" dockerfile attached - "dockerfile.txt" to get it to be acceptable to the file uploader.

dockerfile.txt

$ docker build -f dockerfile,txt -t bug:bug . then

$ docker run -it bug:bug
/ # java
Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: __strdup: symbol not found
Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: __rawmemchr: symbol not found
/ #

[day112]

I see the same thing. Alpine 3.17, adoptium openjdk jre 11.0.18 for x86_64, plus your alpine glibc 2.35-r1 (or r0).

The JVM won't start - two undefined symbols in libjli.so.

Re-pointing /lib64/ld-linux-x86-64.so.2 to /usr/glibc-compat/lib/ld-linux-x86-64.so.2 fixes the problem, but I don't know what the side effects might be.

"Minimal" dockerfile attached - "dockerfile.txt" to get it to be acceptable to the file uploader.

dockerfile.txt

$ docker build -f dockerfile,txt -t bug:bug . then

$ docker run -it bug:bug
/ # java
Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: __strdup: symbol not found
Error relocating /opt/java/openjdk/bin/../lib/jli/libjli.so: __rawmemchr: symbol not found
/ #

f6114f8e863c:/jdk/bin# java -h Error relocating /jdk/bin/../lib/amd64/jli/libjli.so: strdup: symbol not found Error relocating /jdk/bin/../lib/amd64/jli/libjli.so: rawmemchr: symbol not found

I also encountered the same problem, can you share the solution?

[dave-voltdb]

If you're asking me, then it is as I said....

Re-pointing /lib64/ld-linux-x86-64.so.2 to /usr/glibc-compat/lib/ld-linux-x86-64.so.2 fixes the problem, but I don't know what the side effects might be.

[lmzml]

I see the same thing.

FROM alpine:3.18.3
MAINTAINER lmzml

ENV VERSION_GLIBC="2.35-r1"
ENV VERSION_ALIYUN="3.18"

ENV URL_ALIYUN="http://mirrors.aliyun.com/alpine/v${VERSION_ALIYUN}"

ENV URL_GLIBC="https://github.com/sgerrand/alpine-pkg-glibc/releases/download"

ENV URL_PUB="https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub"

RUN echo "${URL_ALIYUN}/main" > /etc/apk/repositories
RUN echo "${URL_ALIYUN}/community" >> /etc/apk/repositories

RUN apk update

RUN apk add --no-cache curl ca-certificates
RUN curl -Lo /etc/apk/keys/sgerrand.rsa.pub "${URL_PUB}"
RUN curl -Lo glibc.apk "${URL_GLIBC}/${VERSION_GLIBC}/glibc-${VERSION_GLIBC}.apk"
RUN curl -Lo glibc-bin.apk "${URL_GLIBC}/${VERSION_GLIBC}/glibc-bin-${VERSION_GLIBC}.apk"
RUN curl -Lo glibc-i18n.apk "${URL_GLIBC}/${VERSION_GLIBC}/glibc-i18n-${VERSION_GLIBC}.apk"
RUN apk add --no-cache --force-overwrite glibc.apk glibc-bin.apk glibc-i18n.apk

RUN /usr/glibc-compat/sbin/ldconfig /lib /usr/glibc-compat/lib

RUN echo 'hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4' >> /etc/nsswitch.conf

ADD java.tar.gz /usr/java/

COPY ./fonts/* /usr/java/lib/fonts/

RUN apk --no-cache add tzdata
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
RUN echo "Asia/Shanghai" > /etc/timezone

COPY ./locale.md /locale.md
RUN cat locale.md | xargs -i /usr/glibc-compat/bin/localedef -i {} -f UTF-8 {}.UTF-8

ENV LANG=en_US.UTF-8
ENV LANGUAGE=en_US.UTF-8

ENV JAVA_HOME=/usr/java
ENV PATH=${PATH}:${JAVA_HOME}/bin

RUN apk del curl
RUN rm -rf glibc.apk glibc-bin.apk glibc-i18n.apk locale.md /var/cache/apk/*

WORKDIR /opt

[dave-voltdb]

I just got back to looking at this for my own use-case. I tried adding this to the APKBUILD file:

  mkdir -p "$pkgdir/lib64"
  ln -sf /usr/glibc-compat/lib64/ld-linux-x86-64.so.2 ${pkgdir}/lib64/ld-linux-x86-64.so.2

Alas,

>>> glibc*: Running postcheck for glibc
>>> ERROR: glibc*: Packages must not put anything under /lib64, use /lib instead
>>> ERROR: glibc*: prepare_subpackages failed

I don't see any way around this. "options: !fhs" does not help.

I therefore have to do it in my image that uses the resulting apk files.