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 [email protected] https://lists.yoctoproject.org/listinfo/meta-virtualization
