[meta-virtualization] [PATCH 1/2] docker-proxy: add recipe for docker-proxy

[Bruce Ashfield]

On Fri, Apr 6, 2018 at 10:23 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 15:48
>> To: Bach, Pascal (BT CPS R&D ZG FW CCP) <pascal.bach at siemens.com>
>> Cc: meta-virtualization at yoctoproject.org
>> Subject: Re: [meta-virtualization] [PATCH 1/2] docker-proxy: add recipe for
>> docker-proxy
>>
>> On Fri, Apr 6, 2018 at 9:41 AM, Pascal Bach <pascal.bach at siemens.com>
>> wrote:
>> > Before docker-proxy was built as part of the docker-recipe but there
>> > in some situations when built for x86_64 under x86_64 it incorrectly
>> > linked against host libraries.
>> > This puts it into a separate recipe that makes use the go.bbclass to
>> > build the binary properly.
>> >
>>
>> As I hinted, I'm going to figure out how to integrate / fix this in the main
>> docker recipe.
>>
>> Having the various SRCREVs managed in multiple recipes is a maintenance
>> pain and recipe for runtime errors.
>>
>> I'll dig into what the go class is doing that is so different from what I've been
>> trying.
>>
>> Can you provide the output of your properly linked docker-proxy, so I can
>> use it as a reference ?
>
> I'm not sure what you mean by output?

I sorted things out using the libnetwork Make infrastructure and some
spelunking into go internals.
I now have it using the sysroot infrastructure, and I can follow along
with SRCREVs and any build internal changes to libnetwork:

file bin/d*
bin/dnet--amd64:         ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 3.2.0,
BuildID[sha1]=bc6059d72a9d6224049542214427bf3c62a41866, not stripped
bin/docker-proxy--amd64: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
for GNU/Linux 3.2.0,
BuildID[sha1]=c52ed7c3b28284a683ade6b4c46ca4f6bad8d1fb, not stripped

Cheers,

Bruce


>
> Pascal
>
> BTW you can also ping me on IRC #yocto as bachp might be quicker to clarify
>



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