[meta-virtualization] docker-proxy links against host libraries

Bruce Ashfield bruce.ashfield at gmail.com
Fri Apr 6 05:38:38 PDT 2018


On Fri, Apr 6, 2018 at 7:48 AM, Pascal Bach <pascal.bach at siemens.com> wrote:
> Hello
>
> I observed some strange linking problem with the "docker-proxy" when building for qemux86-64.
>
> It seems that the binary is linked against the host version of
>
> ```
> $ file image/usr/bin/docker-proxy
> image/usr/bin/docker-proxy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, not stripped
>                                                                                                                  ^^^^^^
> ```
>
> I only noticed the issue on my build as it is a multi lib Debian where the libraries are under /lib64 and /lib32.
> However on the target there there is only /lib to the binary did not work there.
>
> Only the docker-proxy binary is affected by this, the other binaries (docker, dockerd) are fine.
>
> ```
> $ file image/usr/bin/docker
> image/usr/bin/docker: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=c118d2393c7932172ca3e183bb304fe1cff73ce5, not stripped
> ```
>
> I tried to fix the recipe by replacing the build command for docker-proxy [1] with the following line:
>
> ```
> ${GO} build ${GOBUILDFLAGS} -o ${S}/src/import/docker-proxy github.com/docker/libnetwork/cmd/proxy
> ```
>
> But without success the linked loader is still wrong.
>
> It is also worth mentioning that this only happens with x86_64 builds (tried: qemux86-64, genericx64-64) but not with other architectures like armv7.
> I was also able to reproduce this on poky master today (commit: 9ed34e315a8d2db58e212b0770dfa8f4ad00f637).


But what meta-virt commit is your head ?

>
>
> The only solution I found so far is to put the docker-proxy into a separate recipe and add it as a RDEPENDS to docker.
> I will submit a patch for this and you can decide if this would be an acceptable solution.

I don't see what a separate recipe has to do with a fix. I'd rather
keep the build
all in one place.

I guess I can wait to see the recipe, but what's different in that
recipe in the way
that docker-proxy is built, that can't be done in the existing recipe ?

Bruce

>
> Regards
> Pascal
>
> [1] https://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-containers/docker/docker_git.bb#n119
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"


More information about the meta-virtualization mailing list