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

[Bruce Ashfield]

On Fri, Apr 6, 2018 at 10:19 AM, Bach, Pascal <pascal.bach at siemens.com> wrote:
> Hi Bruce
>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield at gmail.com]
>> Sent: Freitag, 6. April 2018 14:47
>> To: Bach, Pascal (BT CPS R&D ZG FW CCP) <pascal.bach at siemens.com>
>> Cc: meta-virtualization at yoctoproject.org; Raymond Danks <ray.danks at se-
>> eng.com>
>> Subject: Re: docker-proxy links against host libraries
>>
>> On Fri, Apr 6, 2018 at 8:38 AM, Bruce Ashfield <bruce.ashfield at gmail.com>
>> wrote:
>> > 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 ?
>
> 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 think I have that sorted now, since the package provides a Makefile.
I had meant to switch to that when I uprev'd, but forgot :(

As I mentioned in my other email, if you can send me the good versus
bad link, then I can compare it to what I get now.

Bruce

>
>> 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



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