[yocto] Installing the SDKs made with meta-mingw

Matt Hoosier matt.hoosier at gmail.com
Wed Mar 16 14:46:50 PDT 2016


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


More information about the yocto mailing list