Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

I am going to slightly amend my comments.

1) When you extract the XZ file you get a TAR. It is when you then extract the 
TAR that you get all the symlink errors.

2) If you run 7ZIP in Administrator mode then you do _not_ get the syslink 
access errors, but apparently neither can you build C applications 
("...gcc/i686-poky-linux/7.2.0/real-ld.exe: cannot find -lgcc").

I would explore further but I think that ZIP files are the only safe way to do 
this, especially since you can avoid Windows Admin mode.

- David

-Original Message-
From: Reyna, David 
Sent: Tuesday, March 06, 2018 12:55 PM
To: Reyna, David; Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: RE: Are Windows SDKs (mingw layer) supposed to work?

Ok, I have it working now.

The problem appears to be that 7ZIP treats "*.xz" files differently than 
"*.zip" files, specifically in the area of translating symlinks. I am using 
version 16.00, 64-bit, 2016-05-10.

With the ZIP file I did get an error about replacing 
"corei7-64-poky-linux\usr\include\linux\netfilter\xt_mark.h" with 
"...\xt_MARK.h" so the upper/lower case problem still arises just as it did 
with the XZ file, but I got ZERO errors about "symbolic links" and that makes 
all the difference.

This is the workflow that worked:

  1) Create the Windows SDK as per normal
  2) Extract the resulting "*.xz" file on your Linux host
  3) Re-package it with ZIP
  4) Extract that file on your Windows host with 7ZIP
  5) Open a Windows shell, start the environment, and build away

Linux:
  $ mkdir sdk_mingw; cd sdk_mingw
  $ unxz -d 
tmp/deploy/sdk/poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.tar.xz
  $ cd ..
  $ zip -r 
poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.zip 
sdk_mingw/

- David

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Reyna, David
Sent: Tuesday, March 06, 2018 8:00 AM
To: Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David <david.re...@windriver.com 
> <mailto:david.re...@windriver.com>> wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Ok, I have it working now.

The problem appears to be that 7ZIP treats "*.xz" files differently than 
"*.zip" files, specifically in the area of translating symlinks. I am using 
version 16.00, 64-bit, 2016-05-10.

With the ZIP file I did get an error about replacing 
"corei7-64-poky-linux\usr\include\linux\netfilter\xt_mark.h" with 
"...\xt_MARK.h" so the upper/lower case problem still arises just as it did 
with the XZ file, but I got ZERO errors about "symbolic links" and that makes 
all the difference.

This is the workflow that worked:

  1) Create the Windows SDK as per normal
  2) Extract the resulting "*.xz" file on your Linux host
  3) Re-package it with ZIP
  4) Extract that file on your Windows host with 7ZIP
  5) Open a Windows shell, start the environment, and build away

Linux:
  $ mkdir sdk_mingw; cd sdk_mingw
  $ unxz -d 
tmp/deploy/sdk/poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.tar.xz
  $ cd ..
  $ zip -r 
poky-glibc-i686-core-image-minimal-corei7-64-toolchain-2.4+snapshot.zip 
sdk_mingw/

- David

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Reyna, David
Sent: Tuesday, March 06, 2018 8:00 AM
To: Hatle, Mark; BURTON, ROSS
Cc: Yocto
Subject: Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com]
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David <david.re...@windriver.com 
> <mailto:david.re...@windriver.com>> wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, I can directly see that 
> it
> is full of symlinks! Why are there symlinks in a Windows-specific 
> tarball?

Often I've extracted it on a linux machine, and then uses zip to recompress it.
(You still need to use 7zip to extract because of the long pathnames that blow 
up winzip.)

> __ __
> 
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:

What version of windows are you using?  The last time I tested this (Rocko) it 
was working properly still, but I tested with Win 7.  So it's possible that 
something more recent has broken it.

I'm not sure if 

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Hi Mark and Ross,

> Ross: Have you tried using 2.4 to identify when it broke?

I will try 2.4 and see if it is different.

> Mark: In the past 7ZIP (when not the admin) would create either copies or 
> 'shortcuts' instead of actual symbolic links.  

I will look to see if there is a new setting in 7ZIP.

> Mark: What version of windows are you using?  

I am using Windows 7.

Thanks,
David

-Original Message-
From: Mark Hatle [mailto:mark.ha...@windriver.com] 
Sent: Tuesday, March 06, 2018 5:40 AM
To: BURTON, ROSS; Reyna, David
Cc: Yocto; WANG, YANG
Subject: Re: Are Windows SDKs (mingw layer) supposed to work?

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need 
> to extend the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David  > wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and  "i686-mingw32">.
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since 
the beginning.  We (WR) had code that would produce a zip format, but that 
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in 
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies 
or 'shortcuts' instead of actual symbolic links.  It sounds like something has 
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, I can directly see that 
> it
> is full of symlinks! Why are there symlinks in a Windows-specific 
> tarball?

Often I've extracted it on a linux machine, and then uses zip to recompress it.
(You still need to use 7zip to extract because of the long pathnames that blow 
up winzip.)

> __ __
> 
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:

What version of windows are you using?  The last time I tested this (Rocko) it 
was working properly still, but I tested with Win 7.  So it's possible that 
something more recent has broken it.

I'm not sure if I'll have time today to retry this with Rocko, but I'll see if 
I can.

--Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Mark Hatle]

On 3/6/18 4:39 AM, Burton, Ross wrote:
> Have you tried using 2.4 to identify when it broke?  Clearly we need to extend
> the selftest so the mingw SDK is actually tested...
> 
> Ross
> 
> On 6 March 2018 at 05:32, Reyna, David  > wrote:
> 
> Hi all,
> 
> __ __
> 
> I am trying to enable a customer for using YP SDKs on Windows. It 
> apparently
> is supposed to work, but I am unable to get past fatal errors.
> 
> __ __
> 
> I have looked for documentation at the YP site and the meta-mingw repo, 
> but
> to no avail.
> 
> __ __
> 
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and .
> 
> __ __
> 
> The SDK builds fine and I get the “*.xz” generated file.

The output format from the Yocto Project of a tarball has been that way since
the beginning.  We (WR) had code that would produce a zip format, but that
stopped working a few releases ago when the archive chaining was reworked..

We've not yet resurrected the code for the .zip generation but probably will in
the next few months.

> __ __
> 
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
> 
> __ __
> 
>   (a) I get more than a hundred errors “Can not create symbolic link: 
> Access
> is denied”. 

This is odd.  In the past 7ZIP (when not the admin) would create either copies
or 'shortcuts' instead of actual symbolic links.  It sounds like something has
changed in 7zip.

> __ __
> 
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus 
> many
> of the libraries and header files in the sysroot.
> 
> __ __
> 
> Am I missing a step?
> 
> __ __
> 
> If I in fact extract this file on my Linux host, I can directly see that 
> it
> is full of symlinks! Why are there symlinks in a Windows-specific 
> tarball?

Often I've extracted it on a linux machine, and then uses zip to recompress it.
(You still need to use 7zip to extract because of the long pathnames that blow
up winzip.)

> __ __
> 
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:

What version of windows are you using?  The last time I tested this (Rocko) it
was working properly still, but I tested with Win 7.  So it's possible that
something more recent has broken it.

I'm not sure if I'll have time today to retry this with Rocko, but I'll see if I
can.

--Mark
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[John, Maxin]

Hi,

>From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] 
>On Behalf Of Burton, Ross
>Sent: Tuesday, March 6, 2018 12:39 PM
>To: Reyna, David L (Wind River) <david.re...@windriver.com>
>Cc: Yocto <yocto@yoctoproject.org>
>Subject: Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?
>
>Have you tried using 2.4 to identify when it broke?  Clearly we need to extend 
>the selftest so the mingw SDK is actually tested...
>
>Ross
>>
>>On 6 March 2018 at 05:32, Reyna, David <david.re...@windriver.com> wrote:
>>Hi all,
>> 
>>I am trying to enable a customer for using YP SDKs on Windows. It apparently 
>>is supposed to work, but I am unable to get past fatal errors.
>>
>>I have looked for documentation at the YP site and the meta-mingw repo, but 
>>to no avail.
>>
>>1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the 
>>latest “meta-mingw” layer added and .
>> 
>>The SDK builds fine and I get the “*.xz” generated file.
>> 
>>2) However, when I use 7ZIP to extract it on my Windows host (which is 
>>recommended for XY files), I get several fatal issues.
>> 
>>  (a) I get more than a hundred errors “Can not create symbolic link: Access 
>>is denied”. 
>> 
>>While I do not care about the ones for the bin tools in the sysroot, I do 
>>care that most of the cross toolchain EXE files are thusly broken, plus many 
>>of the libraries and header files in the sysroot.
>> 
>>Am I missing a step?

Symbolic link errors could be related to the filesystem as FAT has no support 
for symbolic links. Have you tried it on an NTFS partition?

Best Regards,
Maxin

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

Re: [yocto] Are Windows SDKs (mingw layer) supposed to work?

[Burton, Ross]

Have you tried using 2.4 to identify when it broke?  Clearly we need to
extend the selftest so the mingw SDK is actually tested...

Ross

On 6 March 2018 at 05:32, Reyna, David  wrote:

> Hi all,
>
>
>
> I am trying to enable a customer for using YP SDKs on Windows. It
> apparently is supposed to work, but I am unable to get past fatal errors.
>
>
>
> I have looked for documentation at the YP site and the meta-mingw repo,
> but to no avail.
>
>
>
> 1) My project is a simple default “qemux86-64” with YP-2.5 HEAD, with the
> latest “meta-mingw” layer added and .
>
>
>
> The SDK builds fine and I get the “*.xz” generated file.
>
>
>
> 2) However, when I use 7ZIP to extract it on my Windows host (which is
> recommended for XY files), I get several fatal issues.
>
>
>
>   (a) I get more than a hundred errors “Can not create symbolic link:
> Access is denied”.
>
>
>
> While I do not care about the ones for the bin tools in the sysroot, I do
> care that most of the cross toolchain EXE files are thusly broken, plus
> many of the libraries and header files in the sysroot.
>
>
>
> Am I missing a step?
>
>
>
> If I in fact extract this file on my Linux host, I can directly see that
> it is full of symlinks! Why are there symlinks in a Windows-specific
> tarball?
>
>
>
>   (b) If I attempt to build a simple C file from the shell in the SDK
> environment, I either get a silent failure (for the 32-bit toolchain) or a
> blatant error as per:
>
>
>
>   x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory
>
>
>
> I am assuming this error arises from the broken symlinks, specifically all
> those broken files in:
>
>
>
>   SDKDIR\sysroots\i686-pokysdk-mingw32\usr\bin\x86_64-poky-linux-gnux32
> (all zero length):
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-
> addr2line.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-ar.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-as.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++
> filt.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-cpp.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-
> elfedit.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-g++.exe
>
> 03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-gcc-ar.exe
>
> …
>
>
>
>   SDKDIR\sysroots\i686-pokysdk-mingw32\usr\libexec\x86_64-
> poky-linux\gcc\x86_64-poky-linux\7.3.0\*
>
> 03/04/2018  08:29 PM 0 ar.exe
>
> 03/04/2018  08:29 PM 0 as.exe
>
> 02/23/2018  03:48 PM21,962,568 cc1.exe
>
> 02/23/2018  03:48 PM23,256,499 cc1plus.exe
>
> 02/23/2018  03:48 PM   812,905 collect2.exe
>
> 03/04/2018  08:29 PM 0 cpp.exe
>
> 03/04/2018  08:29 PM 0 gcc.exe
>
> 03/04/2018  08:29 PM 0 ld.exe
>
> 02/23/2018  03:48 PM 1,101,508 lto-wrapper.exe
>
> 03/04/2018  08:29 PM 0 nm.exe
>
> 03/04/2018  08:29 PM 0 objcopy.exe
>
> 03/04/2018  08:29 PM 0 objdump.exe
>
> 03/04/2018  08:29 PM 0 ranlib.exe
>
> 03/04/2018  08:29 PM 0 real-ld.exe
>
> 03/04/2018  08:29 PM 0 strip.exe
>
>
>
> 3) I have done ‘–v’ and ProcessMonitor tracing, and it all seems to come
> down to these broken links.
>
>
>
> 4) I see that Yang Wang had the same question (below), and I have not seen
> an answer.
>
>
>
> Please help,
>
> David Reyna
>
>
>
>
>
> *From:* yocto-boun...@yoctoproject.org [mailto:yocto-bounces@
> yoctoproject.org] *On Behalf Of *Wang, Yang Y
> *Sent:* Thursday, August 17, 2017 11:41 PM
> *To:* Yocto
> *Subject:* [yocto] toolchain from meta-mingw gets error
> x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory
>
>
>
> I’m using Yocto krogoth and meta-mingw to build the meta-toolchain for
> windows system. The build is quite smooth.
>
> I extract the built toolchain poky-glibc-x86_64-meta-
> toolchain-core2-64-toolchain-2.1.tar.xz on windows to c:/yocto2.1
>
> However when I try to run a simple build from windows cmd console after I
> set up the environment-setup-core2-64-poky-linux.bat, I got the following
> error.
>
> By further check, it seems the error is related to the symbolic link in
> folder sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-
> linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ where
> the as, ar etc binutiles are the symbolic link to the file in ->
> ../../../../../bin/x86_64-poky-linux/
>
> However on windows, such “../../” symbolic link can’t work. Simply execute
> the symbolic ‘as.exe’ will get error “Access is denied.”
>
>
>
> Anyone has the idea on how to solve this issue?
>
>
>
> c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c
>
> x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory
>
>

[yocto] Are Windows SDKs (mingw layer) supposed to work?

[Reyna, David]

Hi all,

I am trying to enable a customer for using YP SDKs on Windows. It apparently is 
supposed to work, but I am unable to get past fatal errors.

I have looked for documentation at the YP site and the meta-mingw repo, but to 
no avail.

1) My project is a simple default "qemux86-64" with YP-2.5 HEAD, with the 
latest "meta-mingw" layer added and .

The SDK builds fine and I get the "*.xz" generated file.

2) However, when I use 7ZIP to extract it on my Windows host (which is 
recommended for XY files), I get several fatal issues.

  (a) I get more than a hundred errors "Can not create symbolic link: Access is 
denied".

While I do not care about the ones for the bin tools in the sysroot, I do care 
that most of the cross toolchain EXE files are thusly broken, plus many of the 
libraries and header files in the sysroot.

Am I missing a step?

If I in fact extract this file on my Linux host, I can directly see that it is 
full of symlinks! Why are there symlinks in a Windows-specific tarball?

  (b) If I attempt to build a simple C file from the shell in the SDK 
environment, I either get a silent failure (for the 32-bit toolchain) or a 
blatant error as per:

  x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

I am assuming this error arises from the broken symlinks, specifically all 
those broken files in:

  SDKDIR\sysroots\i686-pokysdk-mingw32\usr\bin\x86_64-poky-linux-gnux32 (all 
zero length):
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-addr2line.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-ar.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-as.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-c++filt.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-cpp.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-elfedit.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-g++.exe
03/04/2018  08:29 PM 0 x86_64-poky-linux-gnux32-gcc-ar.exe
...

  
SDKDIR\sysroots\i686-pokysdk-mingw32\usr\libexec\x86_64-poky-linux\gcc\x86_64-poky-linux\7.3.0\*
03/04/2018  08:29 PM 0 ar.exe
03/04/2018  08:29 PM 0 as.exe
02/23/2018  03:48 PM21,962,568 cc1.exe
02/23/2018  03:48 PM23,256,499 cc1plus.exe
02/23/2018  03:48 PM   812,905 collect2.exe
03/04/2018  08:29 PM 0 cpp.exe
03/04/2018  08:29 PM 0 gcc.exe
03/04/2018  08:29 PM 0 ld.exe
02/23/2018  03:48 PM 1,101,508 lto-wrapper.exe
03/04/2018  08:29 PM 0 nm.exe
03/04/2018  08:29 PM 0 objcopy.exe
03/04/2018  08:29 PM 0 objdump.exe
03/04/2018  08:29 PM 0 ranlib.exe
03/04/2018  08:29 PM 0 real-ld.exe
03/04/2018  08:29 PM 0 strip.exe

3) I have done '-v' and ProcessMonitor tracing, and it all seems to come down 
to these broken links.

4) I see that Yang Wang had the same question (below), and I have not seen an 
answer.

Please help,
David Reyna


From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Wang, Yang Y
Sent: Thursday, August 17, 2017 11:41 PM
To: Yocto
Subject: [yocto] toolchain from meta-mingw gets error x86_64-poky-linux-gcc: 
error: CreateProcess: No such file or directory

I'm using Yocto krogoth and meta-mingw to build the meta-toolchain for windows 
system. The build is quite smooth.
I extract the built toolchain 
poky-glibc-x86_64-meta-toolchain-core2-64-toolchain-2.1.tar.xz on windows to 
c:/yocto2.1
However when I try to run a simple build from windows cmd console after I set 
up the environment-setup-core2-64-poky-linux.bat, I got the following error.
By further check, it seems the error is related to the symbolic link in folder 
sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/
 where the as, ar etc binutiles are the symbolic link to the file in -> 
../../../../../bin/x86_64-poky-linux/
However on windows, such "../../" symbolic link can't work. Simply execute the 
symbolic 'as.exe' will get error "Access is denied."

Anyone has the idea on how to solve this issue?

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c
x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory

c:\Yocto2.1>%CC% c:/temp/temp/temp/test.c --verbose
Using built-in specs.
COLLECT_GCC=x86_64-poky-linux-gcc
COLLECT_LTO_WRAPPER=c:/yocto2.1/sysroots/x86_64-pokysdk-mingw32/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/lto-wrapper.exe
Target: x86_64-poky-linux

GNU C11 (GCC) version 5.3.0 (x86_64-poky-linux)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.3, 
MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable