On Thu, Mar 17, 2016 at 10:48 AM, Christopher Larson <clar...@kergoth.com>
wrote:
>
>
> 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.
>
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
