On Mon, Apr 9, 2018 at 11:34 AM, Bach, Pascal <pascal.b...@siemens.com> wrote:
> Hi Bruce
>
>> >>
>> >> 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
>
> I can confirm that it is correctly linking now.
>
> Thanks for the fix.

And thanks for the report and pointers. Since it was running for me, I
probably wouldn't have noticed for ages (and remembered that I forgot
to remove that direct 'go' invocation!)

Cheers,

Bruce

>
> Pascal



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