[yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier <matt.hoosier at gmail.com> wrote:

> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson <clarson at kergoth.com>
> wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson <clarson at kergoth.com>
>> wrote:
>>
>>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier <matt.hoosier at gmail.com>
>>> wrote:
>>>
>>>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier <matt.hoosier at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson <
>>>>> clarson at kergoth.com> wrote:
>>>>>
>>>>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier <matt.hoosier at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160317/eaed3f07/attachment.html>