* Are Windows SDKs (mingw layer) supposed to work?
@ 2018-03-06 5:32 Reyna, David
2018-03-06 10:39 ` Burton, Ross
0 siblings, 1 reply; 7+ messages in thread
From: Reyna, David @ 2018-03-06 5:32 UTC (permalink / raw)
To: Yocto, BURTON, ROSS
[-- Attachment #1: Type: text/plain, Size: 7963 bytes --]
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 <SDKMACHINE ?= "i686-mingw32">.
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 PM 21,962,568 cc1.exe
02/23/2018 03:48 PM 23,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-bounces@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
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 checksum: 4b6c2d45c1da5393637e027504b4f2dd
COLLECT_GCC_OPTIONS='--sysroot=c:\Yocto2.1\\sysroots\core2-64-poky-linux' '-m64' '-march=core2' '-mtune=core2' '-msse3' '-mfpmath=sse' '-v'
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/as.exe -v --64 -o C:\Users\ywang30\AppData\Local\Temp\ccREtk4o.o C:\Users\ywang30\AppData\Local\Temp\ccbqVhdf.s
x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory
c:\Yocto2.1> 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/as.exe
Access is denied.
c:\Yocto2.1>ls 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/ -l
total 67783
lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 ar.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ar.exe
lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 as.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-as.exe
-rwxr-xr-x 1 ywang30 Domain Users 21761467 Aug 18 11:53 cc1.exe
-rwxr-xr-x 1 ywang30 Domain Users 22986939 Aug 18 11:53 cc1plus.exe
-rwxr-xr-x 1 ywang30 Domain Users 1658365 Aug 18 11:53 collect2.exe
lrwxrwxrwx 1 ywang30 Domain Users 62 Aug 18 12:05 cpp.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-cpp.exe
lrwxrwxrwx 1 ywang30 Domain Users 62 Aug 18 12:05 gcc.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-gcc.exe
lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 ld.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ld.exe
-rwxr-xr-x 1 ywang30 Domain Users 129591 Aug 18 11:53 liblto_plugin-0.dll
-rw-r--r-- 1 ywang30 Domain Users 53040 Aug 18 11:53 liblto_plugin.dll.a
-rw-r--r-- 1 ywang30 Domain Users 1381 Aug 18 11:53 liblto_plugin.la
-rwxr-xr-x 1 ywang30 Domain Users 1881552 Aug 18 11:53 lto-wrapper.exe
-rwxr-xr-x 1 ywang30 Domain Users 20913549 Aug 18 11:53 lto1.exe
lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 nm.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-nm.exe
lrwxrwxrwx 1 ywang30 Domain Users 66 Aug 18 12:05 objcopy.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-objcopy.exe
lrwxrwxrwx 1 ywang30 Domain Users 66 Aug 18 12:05 objdump.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-objdump.exe
lrwxrwxrwx 1 ywang30 Domain Users 65 Aug 18 12:05 ranlib.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ranlib.exe
lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 real-ld.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ld.exe
lrwxrwxrwx 1 ywang30 Domain Users 64 Aug 18 12:05 strip.exe -> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-strip.exe
[-- Attachment #2: Type: text/html, Size: 20233 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 5:32 Are Windows SDKs (mingw layer) supposed to work? Reyna, David
@ 2018-03-06 10:39 ` Burton, Ross
2018-03-06 10:53 ` John, Maxin
2018-03-06 13:40 ` Mark Hatle
0 siblings, 2 replies; 7+ messages in thread
From: Burton, Ross @ 2018-03-06 10:39 UTC (permalink / raw)
To: Reyna, David; +Cc: Yocto
[-- Attachment #1: Type: text/plain, Size: 8955 bytes --]
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.reyna@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 <SDKMACHINE ?= "i686-mingw32">.
>
>
>
> 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 PM 21,962,568 cc1.exe
>
> 02/23/2018 03:48 PM 23,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-bounces@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
>
>
>
> 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 checksum: 4b6c2d45c1da5393637e027504b4f2dd
>
> COLLECT_GCC_OPTIONS='--sysroot=c:\Yocto2.1\\sysroots\core2-64-poky-linux'
> '-m64' '-march=core2' '-mtune=core2' '-msse3' '-mfpmath=sse' '-v'
>
> 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/as.exe
> -v --64 -o C:\Users\ywang30\AppData\Local\Temp\ccREtk4o.o
> C:\Users\ywang30\AppData\Local\Temp\ccbqVhdf.s
>
> x86_64-poky-linux-gcc: error: CreateProcess: No such file or directory
>
>
>
>
>
> c:\Yocto2.1> 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/as.exe
>
> Access is denied.
>
>
>
> c:\Yocto2.1>ls 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/
> -l
>
> total 67783
>
> lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 ar.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ar.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 as.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-as.exe
>
> -rwxr-xr-x 1 ywang30 Domain Users 21761467 Aug 18 11:53 cc1.exe
>
> -rwxr-xr-x 1 ywang30 Domain Users 22986939 Aug 18 11:53 cc1plus.exe
>
> -rwxr-xr-x 1 ywang30 Domain Users 1658365 Aug 18 11:53 collect2.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 62 Aug 18 12:05 cpp.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-cpp.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 62 Aug 18 12:05 gcc.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-gcc.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 ld.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ld.exe
>
> -rwxr-xr-x 1 ywang30 Domain Users 129591 Aug 18 11:53 liblto_plugin-0.dll
>
> -rw-r--r-- 1 ywang30 Domain Users 53040 Aug 18 11:53 liblto_plugin.dll.a
>
> -rw-r--r-- 1 ywang30 Domain Users 1381 Aug 18 11:53 liblto_plugin.la
>
> -rwxr-xr-x 1 ywang30 Domain Users 1881552 Aug 18 11:53 lto-wrapper.exe
>
> -rwxr-xr-x 1 ywang30 Domain Users 20913549 Aug 18 11:53 lto1.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 nm.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-nm.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 66 Aug 18 12:05 objcopy.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-objcopy.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 66 Aug 18 12:05 objdump.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-objdump.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 65 Aug 18 12:05 ranlib.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ranlib.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 61 Aug 18 12:05 real-ld.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-ld.exe
>
> lrwxrwxrwx 1 ywang30 Domain Users 64 Aug 18 12:05 strip.exe ->
> ../../../../../bin/x86_64-poky-linux/x86_64-poky-linux-strip.exe
>
[-- Attachment #2: Type: text/html, Size: 17843 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 10:39 ` Burton, Ross
@ 2018-03-06 10:53 ` John, Maxin
2018-03-06 13:40 ` Mark Hatle
1 sibling, 0 replies; 7+ messages in thread
From: John, Maxin @ 2018-03-06 10:53 UTC (permalink / raw)
To: Burton, Ross, Reyna, David L (Wind River); +Cc: Yocto
Hi,
>From: yocto-bounces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Burton, Ross
>Sent: Tuesday, March 6, 2018 12:39 PM
>To: Reyna, David L (Wind River) <david.reyna@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.reyna@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 <SDKMACHINE ?= "i686-mingw32">.
>>
>>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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 10:39 ` Burton, Ross
2018-03-06 10:53 ` John, Maxin
@ 2018-03-06 13:40 ` Mark Hatle
2018-03-06 15:59 ` Reyna, David
1 sibling, 1 reply; 7+ messages in thread
From: Mark Hatle @ 2018-03-06 13:40 UTC (permalink / raw)
To: Burton, Ross, Reyna, David; +Cc: Yocto
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.reyna@windriver.com
> <mailto:david.reyna@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 <SDKMACHINE ?= "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 13:40 ` Mark Hatle
@ 2018-03-06 15:59 ` Reyna, David
2018-03-06 20:55 ` Reyna, David
0 siblings, 1 reply; 7+ messages in thread
From: Reyna, David @ 2018-03-06 15:59 UTC (permalink / raw)
To: Hatle, Mark, BURTON, ROSS; +Cc: Yocto
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.hatle@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.reyna@windriver.com
> <mailto:david.reyna@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 <SDKMACHINE ?=
> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 15:59 ` Reyna, David
@ 2018-03-06 20:55 ` Reyna, David
2018-03-06 21:14 ` Reyna, David
0 siblings, 1 reply; 7+ messages in thread
From: Reyna, David @ 2018-03-06 20:55 UTC (permalink / raw)
To: Reyna, David, Hatle, Mark, BURTON, ROSS; +Cc: Yocto
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-bounces@yoctoproject.org [mailto:yocto-bounces@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.hatle@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.reyna@windriver.com
> <mailto:david.reyna@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 <SDKMACHINE ?=
> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Are Windows SDKs (mingw layer) supposed to work?
2018-03-06 20:55 ` Reyna, David
@ 2018-03-06 21:14 ` Reyna, David
0 siblings, 0 replies; 7+ messages in thread
From: Reyna, David @ 2018-03-06 21:14 UTC (permalink / raw)
To: Hatle, Mark, BURTON, ROSS; +Cc: Yocto
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-bounces@yoctoproject.org [mailto:yocto-bounces@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.hatle@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.reyna@windriver.com
> <mailto:david.reyna@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 <SDKMACHINE ?=
> "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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-03-06 21:15 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-06 5:32 Are Windows SDKs (mingw layer) supposed to work? Reyna, David
2018-03-06 10:39 ` Burton, Ross
2018-03-06 10:53 ` John, Maxin
2018-03-06 13:40 ` Mark Hatle
2018-03-06 15:59 ` Reyna, David
2018-03-06 20:55 ` Reyna, David
2018-03-06 21:14 ` Reyna, David
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.