On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier <matt.hoos...@gmail.com> wrote:
> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson <clar...@kergoth.com> > wrote: > >> >> >> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson <clar...@kergoth.com> >> wrote: >> >>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier <matt.hoos...@gmail.com> >>> wrote: >>> >>>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier <matt.hoos...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson < >>>>> clar...@kergoth.com> wrote: >>>>> >>>>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier <matt.hoos...@gmail.com >>>>>> > wrote: >>>>>> >>>>>>> I've successfully built a Canadian-cross SDK using the meta-mingw >>>>>>> layer. Very nice! >>>>>>> >>>>>>> Because the layer lobotomizes the SDK_PACKAGING_FUNC when >>>>>>> ${SDKMACHINE} is set to a MinGW host, though, the resulting SDK is not >>>>>>> encapsulated into the self-extracting tarball and the corresponding >>>>>>> relocation logic (relocate_sdk.py and so forth) is omitted. >>>>>>> >>>>>>> Any suggestions on how to do the last-mile work to use the SDK on >>>>>>> Windows? Or perhaps nothing is needed at all, except adjusting the >>>>>>> prefixes >>>>>>> built into environment-setup-<arch>? Although that would be nice, I >>>>>>> think at least some installation-time adjustment is necessary though; >>>>>>> when >>>>>>> I do: >>>>>>> >>>>>>> arm-poky-linux-gnueabi-gcc -o foo foo.c >>>>>>> --sysroot=d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi >>>>>>> >>>>>>> , the following happens during linking: >>>>>>> >>>>>>> ld.exe: cannot find /lib/libc.so.6 inside >>>>>>> d:/projects/yocto-sdk/sysroots/cortexa15t2hf-vfp-neon-poky-linux-gnueabi >>>>>>> >>>>>> >>>>> As it turns out, the immediate error here was simply that libc.so.6 >>>>> did not exist, so ld.exe was telling the truth in this case. The symbolic >>>>> links stored in the SDK tarball that would have created libc.so.6 aren't >>>>> meaningful on Windows, so tar just ignores them when unpacking. Presumably >>>>> some fancier handling of the tarball unpacking to simulate symlinks by >>>>> making copies of the pointed-to file would cure this. >>>>> >>>>> >>>>>> >>>>>> Mark Hatle's branch switches to batch files for environment setup and >>>>>> whatnot. I don't know if it addresses the reloc issue or not, but it's a >>>>>> substantial improvement over master. See >>>>>> https://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=mgh/meta-mingw >>>>>> >>>>> >>>>> Thanks, I'll try that. >>>>> >>>> >>>> Mark Hatle's branch does work much more nicely for that. There's still >>>> the problem of what to do with the symlink from the SDK tarballs. Are there >>>> any regular users of these mingw SDKs out there who know the right >>>> expectation on how to extract them? >>>> >>> >>> tar has an option to resolve symlinks to the files, I'd expect you could >>> just add that to the variable for the tar options for the sdk, and it'd >>> just duplicate the symlinks. You'll have extra files, so it'd be larger, >>> but at least it'd be functional. >>> >> >> Erm, I meant duplicate the files, not the symlinks :) The symlinks would >> be resolved to files. Clearly I haven't had enough caffeine yet today. >> > > Thanks. > > If you're thinking of "tar -h -xf ... ", I'd given that a try prior to my > previous message. It doesn't seem to have any effect on the outcome (at > least, for the copy of 'tar' bundled into my installation of MinGW and > MSys). > No, I was thinking of changing the tar *creation* rather than extraction, so the symlinks are followed and stored as files in the tarball.
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto