[yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Thu, Mar 17, 2016 at 11:56 AM, Christopher Larson <clarson at kergoth.com>
wrote:

>
>
> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160317/9f301d69/attachment.html>