Hi Bruce > -----Original Message----- > From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com] > Sent: Freitag, 6. April 2018 14:47 > To: Bach, Pascal (BT CPS R&D ZG FW CCP) <pascal.b...@siemens.com> > Cc: meta-virtualization@yoctoproject.org; Raymond Danks <ray.danks@se- > eng.com> > Subject: Re: docker-proxy links against host libraries > > On Fri, Apr 6, 2018 at 8:38 AM, Bruce Ashfield <bruce.ashfi...@gmail.com> > wrote: > > On Fri, Apr 6, 2018 at 7:48 AM, Pascal Bach <pascal.b...@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 ?
Sorry forgot to mention, I was using: e9d74162a9bfdbf0a51f230ad9bedeab920552f4 > >> > >> > >> 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 guess there is nothing that could not be done in the current recipe. However as the docker-proxy is a proper go package it can easily be built with a simple recipe using go.bbclass. So for me this was the simplest solution as I could not figure out how to call go build properly. > 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. The issue was already there before 18.03 uprev. So I don't think it is related. I was using pyro before with docker 1.1x something where I didn't notice the issue there. Pascal -- _______________________________________________ meta-virtualization mailing list meta-virtualization@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-virtualization