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.

Pascal
-- 
_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization

Reply via email to