I didn't catch anyone on IRC so...
On one machine (different distro) I am building an executable:
root@0693f9aa601d:/go# ldd bin/server
linux-vdso.so.1 (0x00007fffa7355000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff1480c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff147ea8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff147afe000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1482cf000)
Now in a docker-alphine based container I trying to run it:
/app # ls -la
total 9880
drwxr-xr-x 2 root root 4096 Feb 28 14:31 .
drwxr-xr-x 28 root root 4096 Feb 28 14:47 ..
-rwxr-xr-x 1 root root 10105256 Feb 28 14:27 server
/app # ldd server
/lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
/app # ./server
sh: ./server: not found
Yet it just gives not found. WHAT?
Any idea what's going on?
So you've tried to put glibc into the container?
On Sat, Feb 28, 2015 at 8:59 AM, Torsten Curdt [email protected]
wrote:
I didn't catch anyone on IRC so...
On one machine (different distro) I am building an executable:
root@0693f9aa601d:/go# ldd bin/server
linux-vdso.so.1 (0x00007fffa7355000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff1480c5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff147ea8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff147afe000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff1482cf000)Now in a docker-alphine based container I trying to run it:
/app # ls -la
total 9880
drwxr-xr-x 2 root root 4096 Feb 28 14:31 .
drwxr-xr-x 28 root root 4096 Feb 28 14:47 ..
-rwxr-xr-x 1 root root 10105256 Feb 28 14:27 server
/app # ldd server
/lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000)
/app # ./server
sh: ./server: not foundYet it just gives not found. WHAT?
Any idea what's going on?
—
Reply to this email directly or view it on GitHub
https://github.com/gliderlabs/docker-alpine/issues/12.
Jeff Lindsay
http://progrium.com
@progrium actually I didn't - I expected that to be in the image.
If it wasn't - shouldn't ldd show that?
FROM gliderlabs/alpine:3.1
ADD bin /app
WORKDIR /app
But mostly I am confused about the not found.
Is that what you get when a lib is missing?
Alpine is based on musl not glibc, so you either need to build against musl
or put glibc into the container.
On Sat, Feb 28, 2015 at 9:16 AM, Torsten Curdt [email protected]
wrote:
@progrium https://github.com/progrium actually I didn't - I expected
that to be in the image.If it wasn't - shouldn't ldd show that?
FROM gliderlabs/alpine:3.1
ADD bin /app
WORKDIR /app—
Reply to this email directly or view it on GitHub
https://github.com/gliderlabs/docker-alpine/issues/12#issuecomment-76529944
.
Jeff Lindsay
http://progrium.com
Yes, that is often the error you see.
But why does it say libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f3638d64000) then?
Because that's where it expects to find it. That file does not exist.
On Sat, Feb 28, 2015 at 9:23 AM, Torsten Curdt [email protected]
wrote:
But why does it say libc.so.6 => /lib64/ld-linux-x86-64.so.2
(0x7f3638d64000) then?—
Reply to this email directly or view it on GitHub
https://github.com/gliderlabs/docker-alpine/issues/12#issuecomment-76530177
.
Jeff Lindsay
http://progrium.com
But shouldn't ldd then print not found?
I've not seen that. Is that what it's supposed to do? Maybe busybox ldd is
different. It certainly makes your original error make more sense right?
On Sat, Feb 28, 2015 at 9:27 AM, Torsten Curdt [email protected]
wrote:
But shouldn't ldd then print not found?
—
Reply to this email directly or view it on GitHub
https://github.com/gliderlabs/docker-alpine/issues/12#issuecomment-76530352
.
Jeff Lindsay
http://progrium.com
Totally - makes we wonder why it doesn't print the not found though. It should.
The musl smells like a lot of trouble.
I guess I'll stick to busybox for now then.
Thanks for your help!
@tcurdt
I also encountered the same problem.
use CGO_ENABLED=0 is ok.
linke :
CGO_ENABLED=0 go build hello.go
Most helpful comment
@tcurdt
I also encountered the same problem.
use CGO_ENABLED=0 is ok.
linke :
CGO_ENABLED=0 go build hello.go