Error relocating /lib/ld-linux-x86-64.so.2: unsupported relocation type 37

[RonaldinhoL]

i am compiling v8 in alpine

i got
Error relocating /lib/ld-linux-x86-64.so.2: unsupported relocation type 37
Error relocating ./torque: __vfprintf_chk: symbol not found
Error relocating ./torque: __vsnprintf_chk: symbol not found
erros in 2.34, no idea why

[benyue1978]

I have the same issue here.

I run alpine 3.17.2

docker run -it alpine:3.17.2 /bin/sh
wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-bin-2.35-r0.apk
apk --no-cache --force-overwrite add glibc-2.35-r0.apk glibc-bin-2.35-r0.apk
ldd /lib/ld-linux-x86-64.so.2

I got this error:
/lib/ld-musl-x86_64.so.1 (0x7f0765c75000)
Error relocating /lib/ld-linux-x86-64.so.2: unsupported relocation type 37

version 2.32-r0 is ok though.

[sgerrand]

@benyue1978: It looks to me like you're trying to mix the musl ldd with files which aren't compatible. Using /usr/glibc-compat/bin/ldd works fine for me as does the following Dockerfile:

FROM alpine:3.17.2

RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-bin-2.35-r0.apk
RUN apk --no-cache --force-overwrite add glibc-2.35-r0.apk glibc-bin-2.35-r0.apk

RUN /usr/glibc-compat/bin/ldd /lib/ld-linux-x86-64.so.2

[sgerrand]

@RonaldinhoL: 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.

[chadlwilson]

To me, this also seems likely the same as #175, #176, #181.

After installing glibc-bin, anything that looks for lib64 is finding musl libc with the libc6-compat layer rather than using glibc.

If this problem is specific to 2.35 their problem may be more adequately demonstrated by

FROM alpine:3.17.2

RUN wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-2.35-r0.apk
RUN wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.35-r0/glibc-bin-2.35-r0.apk
RUN apk --no-cache --force-overwrite add glibc-2.35-r0.apk glibc-bin-2.35-r0.apk

RUN ls -al /lib64/ld-linux-x86-64.so.2

#9 [6/6] RUN ls -al /lib64/ld-linux-x86-64.so.2
#9 0.466 lrwxrwxrwx    1 root     root            26 Apr 14 04:57 /lib64/ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1

Lots of glibc things are linked against /lib64/ld-linux-x86-64.so.2 so are breaking in weird ways without the lib64 link pointing to this glibc package.

[dave-voltdb]

I ran into a similar error in different circumstances. I was running an image based on the prebuilt eclipse-temurin docker image, plus alpine-pkg-glibc (2.3x, any available x), and homebrew Java & C++ code built on some glibc system.

Unknown to me, the eclipse-temurin image now has a JVM linked against musl, which was fine until the Java program tried to load a native library that wanted glibc. Result: the mysterious 'unsupported reloc type 37'. This particular problem vanished when I figured out I can't use the eclipse-temurin docker image as a replacement for the older adoptopenjdk images

This seems rather different to the 'missing lib64 symlink' issue with 2.35 in that it happened with 2.33 and 2.34, and was cured by getting the right JVM. It's a mixed-libc problem, though, so maybe there's a fundamental common issue.

I know this is a pretty vague description, but maybe it'll help.

[chadlwilson]

Yeah, fair enough - I have also seen it in cases where there is an accidental attempt to mix musl and glibc-linked binaries. I got a similar error using a musl JVM build with a different glibc native load library. Tend to agree with you that this is a common mixing problem and probably always a risk to some extent when using glibc on Alpine. You really need everything pure musl, or everything musl (but works with gcompat or libc6-compat shim-like tools...) or everything glibc using this package)

Problems like this are the reasons that a number of the folks on the Alpine team are quite against packages and approaches like this to put glibc back onto a musl-based OS such as Alpine (despite its utility they would seemingly prefer folks use a minimal glibc-based distro instead of Alpine)