On Fri, Apr 6, 2018 at 8:38 AM, Bruce Ashfield <[email protected]> wrote: > On Fri, Apr 6, 2018 at 7:48 AM, Pascal Bach <[email protected]> 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 ? >
I can see a similar link pattern here (but this would have been an existing issue, unrelated to the recent docker uprevs), so I'll have a go at fixing it this morning. Bruce > 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" -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" -- _______________________________________________ meta-virtualization mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
