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 ?
>
>>
>>
>> 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
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization

Reply via email to