On Thu, Mar 17, 2016 at 11:56 AM, Christopher Larson <clar...@kergoth.com> wrote:
> > > 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. > Ah. In that case, this is apparently a situation with no good general solution. The conf files used in meta-mingw make a point of saying not to attempt that, as it's been observed to result in infinite loops at tarball creation-time. The particular blurb in question says: # Causes an endless loop #SDKTAROPTS_append = "-h --hard-dereference" The commit that adopted this policy says that the looping is triggered on certain cross-compilers' complements of system headers. That seems like something I can test for and be fairly confident whether or not it'll strike my particular configuration, so I imagine the symlink expansion can safely be re-enabled on site-local configurations with little risk. Thanks for the suggestions.
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto