Re: [yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson 
wrote:

>
>
> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
> wrote:
>
>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
>> wrote:
>>
>>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
>>> 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 
> 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-? 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).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
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-? 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
>

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
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier  wrote:

> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson 
> wrote:
>
>>
>>
>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
>> wrote:
>>
>>> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
>>> wrote:
>>>
 On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
 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 > > 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-? 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Thu, Mar 17, 2016 at 11:56 AM, Christopher Larson 
wrote:

>
>
> On Thu, Mar 17, 2016 at 9:48 AM Matt Hoosier 
> wrote:
>
>> On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson > > wrote:
>>
>>>
>>>
>>> On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
>>> wrote:
>>>
 On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
 wrote:

> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
> 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-? 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

[yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

Hi,

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

Cheers,
Matt
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
wrote:

> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
> 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-? 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Thu, Mar 17, 2016 at 8:47 AM Christopher Larson 
wrote:

> On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier 
> wrote:
>
>> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
>> wrote:
>>
>>>
>>>
>>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson >> > wrote:
>>>
 On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
 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-? 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

Re: [yocto] Installing the SDKs made with meta-mingw

[Christopher Larson]

On Thu, Mar 17, 2016 at 8:43 AM Matt Hoosier  wrote:

> On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
> wrote:
>
>>
>>
>> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
>> wrote:
>>
>>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
>>> 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-? 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.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Installing the SDKs made with meta-mingw

[Matt Hoosier]

On Wed, Mar 16, 2016 at 4:46 PM, Matt Hoosier 
wrote:

>
>
> On Wed, Mar 16, 2016 at 4:40 PM, Christopher Larson 
> wrote:
>
>> On Wed, Mar 16, 2016 at 2:32 PM, Matt Hoosier 
>> 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-? 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?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto