devcontainer with denoland/deno:alpine not working

[cirolosapio]

using denoland/deno:alpine as a base image to run a devcontainer run in this error:

Error relocating /usr/local/lib/libgcc_s.so.1: _dl_find_object: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_model: symbol not found

[lucacasonato]

Probably vscode depends on glibc, and thus can not run on alpine. I don't think these errors come from Deno.

[cirolosapio]

no vscode does not require gclib afaik
if you use alpine image instead it works

using this reproduction check compose.yml and try switching image from alpine and denoland/deno:alpine

[vaaski]

i just ran into a similar issue on denoland/deno:alpine trying to use ffmpeg.

❯ docker run --rm -it denoland/deno:alpine sh

/ # apk add ffmpeg

[...]

/ # ffmpeg
Error relocating /usr/local/lib/libgcc_s.so.1: _dl_find_object: symbol not found

works fine on the regular alpine image

[jd1378]

I'm also getting similar errors due to switching to denoland/deno:alpine-2.0.3 from alpine:3.20.3, when using php:

PHP Warning:  PHP Startup: Unable to load dynamic library 'imagick' (tried: /usr/lib/php83/modules/imagick (Error loading shared library /usr/lib/php83/modules/imagick: No such file or directory), /usr/lib/php83/modules/imagick.so (Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found)) in Unknown on line 0

this is a serious issue

[jd1378]

#350 is probably related

[Meldiron]

Also facing this issue.

RUN apk update && apk add --no-cache npm
RUN npm install pnpm yarn -g

 > [11/18] RUN npm install pnpm yarn -g:
0.408 Error relocating /usr/local/lib/libgcc_s.so.1: _dl_find_object: symbol not found
0.408 Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found
0.408 Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_model: symbol not found
------
Dockerfile:27
--------------------
  25 |     ENV DENO_DIR=/usr/builds/deno-cache
  26 |     RUN apk update && apk add --no-cache npm
  27 | >>> RUN npm install pnpm yarn -g
  28 |     # DOCKERFILE-X:END file="./deno" includedBy="dockerfile_1730902581" includeType="include"
  29 |     # DOCKERFILE-X:START file="./base-after" includedBy="dockerfile_1730902581" includeType="include"
--------------------
ERROR: failed to solve: process "/bin/sh -c npm install pnpm yarn -g" did not complete successfully: exit code: 127

[bartlomieju]

@Meldiron which version of the dockerfile are you using?

[Tate-CC]

I'm hitting this issue too when trying to run lftp on the denoland/deno:alpine-2.1.3 image.

I was able to work around it by updating the LD_LIBRARY_PATH environment variable. It looks like the base deno alpine Docker image has LD_LIBRARY_PATH=/usr/local/lib which points to the libgcc_s.so.1 that is causing issues. On a plain alpine:3 Docker image it looks like lftp is linked to /usr/lib/libgcc_s.so.1 instead.

So by setting LD_LIBRARY_PATH=/usr/lib when running lftp I was able to run it in the Deno image without issue.

Interestingly, after updating the LD_LIBRARY_PATH deno also seemed to run fine, and when looking at the deno binary with ldd it looks like it's also failing to find some symbols in /usr/local/lib/libgcc_s.so.1 🤔

This is a bit above my pay grade so I'm not exactly sure of the repercussions, but could this potentially be resolved by not providing a custom libgcc in the base Dockerfile and instead using the one from /usr/lib (which I assume is being installed from apk)

[deveyus]

I was having some trouble getting the VSCode Remote Server to run with Deno in the official image. At first I had installed gcompat and gotten the VSCode server working, but that broke Deno, after reading @Tate-CC 's answer I realized I could just use the following and got both of them working.

ENV LD_LIBRARY_PATH /usr/lib:/usr/local/lib

[retifrav]

[...] a similar issue on denoland/deno:alpine trying to use ffmpeg

It is probably fair to say that despite numerous errors in ldd report:

# ldd $(which deno)
	/lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1 (0x7f343eea4000)
	librt.so.1 => /lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3445d1d000)
	ld-linux-x86-64.so.2 => /usr/local/lib/ld-linux-x86-64.so.2 (0x7f343ee6f000)
Error relocating /usr/local/lib/libgcc_s.so.1: _dl_find_object: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_model: symbol not found
Error relocating /usr/local/lib/ld-linux-x86-64.so.2: unsupported relocation type 37
Error relocating /bin/deno: __cmsg_nxthdr: symbol not found
Error relocating /bin/deno: __isnanf: symbol not found
Error relocating /bin/deno: __isinf: symbol not found
Error relocating /bin/deno: __isnan: symbol not found
Error relocating /bin/deno: __memcpy_chk: symbol not found
Error relocating /bin/deno: backtrace: symbol not found
Error relocating /bin/deno: backtrace_symbols_fd: symbol not found
Error relocating /bin/deno: backtrace_symbols: symbol not found
Error relocating /bin/deno: __vfprintf_chk: symbol not found
Error relocating /bin/deno: __vsnprintf_chk: symbol not found
Error relocating /bin/deno: __sysconf: symbol not found
Error relocating /bin/deno: __mbrlen: symbol not found
Error relocating /bin/deno: strtoll_l: symbol not found
Error relocating /bin/deno: strtoull_l: symbol not found
Error relocating /bin/deno: __register_atfork: symbol not found
Error relocating /bin/deno: malloc_trim: symbol not found
Error relocating /bin/deno: __res_init: symbol not found
Error relocating /bin/deno: gnu_get_libc_version: symbol not found

the deno itself seems to run with no(?) problems, so one perhaps could state that for its main(?) purpose the denoland/deno:alpine image works fine.

But I was still quite surprised to see that this is still an issue 1.5 years since the original report was filed. The steps to reproduce and work around the problem are still the same:

$ docker run -it --rm denoland/deno:alpine /bin/ash

# echo $LD_LIBRARY_PATH
/usr/local/lib

# apk add ffmpeg

# ffmpeg -version
Error relocating /usr/local/lib/libgcc_s.so.1: _dl_find_object: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_indicator_init: symbol not found
Error relocating /usr/local/lib/libgcc_s.so.1: __cpu_model: symbol not found
Error relocating /usr/lib/libhwy.so.1: __extendbfsf2: symbol not found

# LD_LIBRARY_PATH=/usr/lib:$LD_LIBRARY_PATH ffmpeg -version
ffmpeg version 8.0.1 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.2.0 (Alpine 15.2.0)
...

And the reason why I wanted to run FFmpeg in a container based on denoland/deno:alpine image is that yt-dlp needs a JS-engine now (and FFmpeg is used by yt-dlp to merge the downloaded streams into the final container), and since Deno is listed as the recommended one, I decided to base my yt-dlp image on denoland/deno:alpine (and I reckon more people will be arriving to that same idea).