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.
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
