Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
x86_64 images #47
how did you determine that there is only a 32-bit version?
it looks like 64-bit to me:
$ docker run --rm -it alpine:3.2 sh / # apk update fetch http://dl-4.alpinelinux.org/alpine/v3.2/main/x86_64/APKINDEX.tar.gz v3.2.0-41-g0cfd265 [http://dl-4.alpinelinux.org/alpine/v3.2/main] OK: 5258 distinct packages available / # apk info -P musl musl-1.1.9-r2 provides: so:libc.musl-x86_64.so.1=1 / # apk add file (1/1) Installing file (5.22-r0) Executing busybox-1.23.2-r0.trigger OK: 9 MiB in 16 packages / # file -L /bin/sh /bin/sh: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped / # /lib/ld-musl-x86_64.so.1 --list /bin/busybox /lib/ld-musl-x86_64.so.1 (0x7fa8f50e2000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7fa8f50e2000)
I've been trying to get docker-compose to run in an alpine based container and considered the following behavior as an architecture mismatch:
Apparently I was missing some dependencies. Found a working docker-compose alpine based image here:
The difference in image size is terrifying!
it turns out to be a libc mismatch.
it's useful to run
the other day i looked at https://github.com/docker/compose/blob/master/Dockerfile with a thought to converting that debian-based builder into an alpine-based builder. the end result should be standalone docker-compose linked with musl instead of glibc.
in cases where you want to put a closed-source binary into an alpine container, this trick to get glibc in alpine is useful.
Hi, just to let you know, i've been able to run some
$ /lib/ld-musl-x86_64.so.1 bin args
It could have some side-effect as exposed here: http://www.musl-libc.org/faq.html (section: