Re: Yocto toolchain for Windows

Re: Yocto toolchain for Windows

[Francois Retief]

[-- Attachment #1: Type: text/plain, Size: 7595 bytes --]

Hi Krzysztof,

My understanding is that MinGW is the libc library for Win32 environments.
So we need to "replace" eglibc with mingw for all code that execute on the
Win32 platform.  In the case of OpenEmbedded, it is all packages that start
with "nativesdk-" when is SDKMACHINE="x86_64-mingw32".

Over the weekend I worked on this by disabling the eglibc recipes and
seeing what packages are missing.  The eglibc recipe provides the
"virtual/nativesdk-libc" package. My understanding is that this virtual
package must be implemented by MingGW.  In the process I also found that
pthreads-win32 was needed and added a recipe for this.

I ended up at a point where nativesdk-zlib is actually looking for libc and
not finding it.  Currently I am trying to understand exactly what is
required by "nativesdk-*" packages, and what mingw provides, in the hope of
understanding where the mismatch is or where my understanding of the system
breaks down.  ;-)

Will keep you posted.

Cheers,
  Francois

$ SDKMACHINE=x86_64-mingw32 bitbake nativesdk-zlib
...
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j2 -e MAKEFLAGS=
| x86_64-oesdk-mingw32-gcc
--sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32 -shared
-Wl,-soname,libz.so.1,--version-script,zlib.map
-isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include
-O2 -pipe  -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 adler32.lo
crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo
zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo
-lc -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib
-Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib
-Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib
-Wl,-O1 -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib
-Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib
-Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib
-Wl,-O1
| x86_64-oesdk-mingw32-gcc
--sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32
-isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include
-O2 -pipe -o minigzip64 minigzip64.o -L. libz.a
| /opt/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-oesdk-mingw32/gcc/x86_64-oesdk-mingw32/4.8.1/ld:
cannot find -lc
| collect2: error: ld returned 1 exit status
| make: *** [libz.so.1.2.8] Error 1
| make: *** Waiting for unfinished jobs....
| ERROR: oe_runmake failed
...


On 12 August 2013 12:13, Sywula, Krzysztof M
<krzysztof.m.sywula@intel.com>wrote:

>  Francois,****
>
> I tried compiling the same eglibc version as Yocto uses under
> mingw32/Cygwin. Apparently there is no port for these.****
>
> ** **
>
> Mingw32:****
>
> $ ../eglibc-2.17/libc/configure****
>
> checking build system type... i686-pc-mingw32****
>
> checking host system type... i686-pc-mingw32****
>
> checking for gcc... gcc****
>
> checking for suffix of object files... o****
>
> checking whether we are using the GNU C compiler... yes****
>
> checking whether gcc accepts -g... yes****
>
> checking for gcc option to accept ISO C89... none needed****
>
> checking how to run the C preprocessor... gcc -E****
>
> checking for g++... g++****
>
> checking whether we are using the GNU C++ compiler... yes****
>
> checking whether g++ accepts -g... yes****
>
> checking for readelf... readelf****
>
> checking for sysdeps preconfigure fragments... x86_64****
>
> configure: running configure fragment for add-on libidn****
>
> configure: running configure fragment for add-on nptl****
>
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm
> hppa****
>
> ia64 m68k mips powerpc tile****
>
> *** The GNU C library is currently not available for this platform.****
>
> *** So far nobody cared to port it and if there is no volunteer it****
>
> *** might never happen.  So, if you have interest to see glibc on****
>
> *** this platform visit****
>
> ***     http://www.gnu.org/software/libc/porting.html****
>
> *** and join the group of porters****
>
> ** **
>
> Cygwin:****
>
> $ ../eglibc-2.17/libc/configure****
>
> checking build system type... i686-pc-cygwin****
>
> checking host system type... i686-pc-cygwin****
>
> checking for gcc... gcc****
>
> checking for suffix of object files... o****
>
> checking whether we are using the GNU C compiler... yes****
>
> checking whether gcc accepts -g... yes****
>
> checking for gcc option to accept ISO C89... none needed****
>
> checking how to run the C preprocessor... gcc -E****
>
> checking for g++... g++****
>
> checking whether we are using the GNU C++ compiler... yes****
>
> checking whether g++ accepts -g... yes****
>
> checking for readelf... readelf****
>
> checking for sysdeps preconfigure fragments... x86_64****
>
> configure: running configure fragment for add-on libidn****
>
> configure: running configure fragment for add-on nptl****
>
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm
> hppa ia64 m68k mips powerpc tile****
>
> *** The GNU C library is currently not available for this platform.****
>
> *** So far nobody cared to port it and if there is no volunteer it****
>
> *** might never happen.  So, if you have interest to see glibc on****
>
> *** this platform visit****
>
> ***     http://www.gnu.org/software/libc/porting.html****
>
> *** and join the group of porters****
>
> ** **
>
> ** **
>
> To see why is eglibc needed do:****
>
> bitbake <recipe> -c populate_sdk –g****
>
> and:****
>
> less package-depends.dot****
>
> ** **
>
> That’s what it gives:****
>
> "nativesdk-eglibc-initial" [label="nativesdk-eglibc-initial
> :2.17-r3\nvirtual:nativesdk:/build/kmsywula****
>
> 3/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb"]****
>
> "nativesdk-eglibc-initial" ->
> "virtual/x86_64-pokysdk-mingw32-gcc-initial-crosssdk"****
>
> "nativesdk-eglibc-initial" -> "nativesdk-linux-libc-headers"****
>
> "nativesdk-eglibc-initial" -> "chrpath-replacement-native"****
>
> "nativesdk-eglibc-initial" -> "autoconf-native"****
>
> "nativesdk-eglibc-initial" -> "automake-native"****
>
> "nativesdk-eglibc-initial" -> "libtool-native"****
>
> "nativesdk-eglibc-initial" -> "kconfig-frontends-native"****
>
> "nativesdk-eglibc-initial" -> "gnu-config-native"****
>
> ** **
>
> ** **
>
> So as long as there is no port for mingw32/Cygwin we are blocked. Any
> ideas?****
>
> ** **
>
> Thanks,****
>
> Krzysztof****
>
> ** **
>
> *From:* Francois Retief [mailto:fgretief@gmail.com]
> *Sent:* Friday, August 09, 2013 6:33 PM
>
> *To:* Sywula, Krzysztof M
> *Subject:* Re: Yocto toolchain for Windows****
>
> ** **
>
> Hi Krzysztof,****
>
> Yup, that is the same point where I am stuck at the moment. I sent an
> email to oe-core mailing list about this issue.
>
>
> http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082509.html
> ****
>
> Hoping for a response from the OE community soon.****
>
> Cheers,****
>
>   Francois****
>
> ** **
>

[-- Attachment #2: Type: text/html, Size: 21060 bytes --]

Re: Yocto toolchain for Windows

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 7933 bytes --]


On Aug 12, 2013, at 6:34 AM, Francois Retief <fgretief@gmail.com> wrote:

> Hi Krzysztof,
> 
> My understanding is that MinGW is the libc library for Win32 environments. So we need to "replace" eglibc with mingw for all code that execute on the Win32 platform.  In the case of OpenEmbedded, it is all packages that start with "nativesdk-" when is SDKMACHINE="x86_64-mingw32".
> 
> Over the weekend I worked on this by disabling the eglibc recipes and seeing what packages are missing.  The eglibc recipe provides the "virtual/nativesdk-libc" package. My understanding is that this virtual package must be implemented by MingGW.  In the process I also found that pthreads-win32 was needed and added a recipe for this.

Not really but if you stub eglibc from nativesdk out then make sure the host libc is plugged in correctly at all places where its expected. Its safer to let it
build its own nativesdk eglibc. Since we also modify the shared library load paths in dynamic linker to use own nativesdk libraries first if available

> 
> I ended up at a point where nativesdk-zlib is actually looking for libc and not finding it.  Currently I am trying to understand exactly what is required by "nativesdk-*" packages, and what mingw provides, in the hope of understanding where the mismatch is or where my understanding of the system breaks down.  ;-) 
> 
> Will keep you posted.
> 
> Cheers,
>   Francois
> 
> $ SDKMACHINE=x86_64-mingw32 bitbake nativesdk-zlib
> ...
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j2 -e MAKEFLAGS=
> | x86_64-oesdk-mingw32-gcc  --sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32 -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include -O2 -pipe  -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-O1 -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-O1
> | x86_64-oesdk-mingw32-gcc  --sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32 -isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include -O2 -pipe -o minigzip64 minigzip64.o -L. libz.a
> | /opt/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-oesdk-mingw32/gcc/x86_64-oesdk-mingw32/4.8.1/ld: cannot find -lc
> | collect2: error: ld returned 1 exit status
> | make: *** [libz.so.1.2.8] Error 1
> | make: *** Waiting for unfinished jobs....
> | ERROR: oe_runmake failed
> ...
> 
> 
> On 12 August 2013 12:13, Sywula, Krzysztof M <krzysztof.m.sywula@intel.com> wrote:
> Francois,
> 
> I tried compiling the same eglibc version as Yocto uses under mingw32/Cygwin. Apparently there is no port for these.
> 
>  
> 
> Mingw32:
> 
> $ ../eglibc-2.17/libc/configure
> 
> checking build system type... i686-pc-mingw32
> 
> checking host system type... i686-pc-mingw32
> 
> checking for gcc... gcc
> 
> checking for suffix of object files... o
> 
> checking whether we are using the GNU C compiler... yes
> 
> checking whether gcc accepts -g... yes
> 
> checking for gcc option to accept ISO C89... none needed
> 
> checking how to run the C preprocessor... gcc -E
> 
> checking for g++... g++
> 
> checking whether we are using the GNU C++ compiler... yes
> 
> checking whether g++ accepts -g... yes
> 
> checking for readelf... readelf
> 
> checking for sysdeps preconfigure fragments... x86_64
> 
> configure: running configure fragment for add-on libidn
> 
> configure: running configure fragment for add-on nptl
> 
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa
> 
> ia64 m68k mips powerpc tile
> 
> *** The GNU C library is currently not available for this platform.
> 
> *** So far nobody cared to port it and if there is no volunteer it
> 
> *** might never happen.  So, if you have interest to see glibc on
> 
> *** this platform visit
> 
> ***     http://www.gnu.org/software/libc/porting.html
> 
> *** and join the group of porters
> 
>  
> 
> Cygwin:
> 
> $ ../eglibc-2.17/libc/configure
> 
> checking build system type... i686-pc-cygwin
> 
> checking host system type... i686-pc-cygwin
> 
> checking for gcc... gcc
> 
> checking for suffix of object files... o
> 
> checking whether we are using the GNU C compiler... yes
> 
> checking whether gcc accepts -g... yes
> 
> checking for gcc option to accept ISO C89... none needed
> 
> checking how to run the C preprocessor... gcc -E
> 
> checking for g++... g++
> 
> checking whether we are using the GNU C++ compiler... yes
> 
> checking whether g++ accepts -g... yes
> 
> checking for readelf... readelf
> 
> checking for sysdeps preconfigure fragments... x86_64
> 
> configure: running configure fragment for add-on libidn
> 
> configure: running configure fragment for add-on nptl
> 
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa ia64 m68k mips powerpc tile
> 
> *** The GNU C library is currently not available for this platform.
> 
> *** So far nobody cared to port it and if there is no volunteer it
> 
> *** might never happen.  So, if you have interest to see glibc on
> 
> *** this platform visit
> 
> ***     http://www.gnu.org/software/libc/porting.html
> 
> *** and join the group of porters
> 
>  
> 
>  
> 
> To see why is eglibc needed do:
> 
> bitbake <recipe> -c populate_sdk –g
> 
> and:
> 
> less package-depends.dot
> 
>  
> 
> That’s what it gives:
> 
> "nativesdk-eglibc-initial" [label="nativesdk-eglibc-initial :2.17-r3\nvirtual:nativesdk:/build/kmsywula
> 
> 3/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb"]
> 
> "nativesdk-eglibc-initial" -> "virtual/x86_64-pokysdk-mingw32-gcc-initial-crosssdk"
> 
> "nativesdk-eglibc-initial" -> "nativesdk-linux-libc-headers"
> 
> "nativesdk-eglibc-initial" -> "chrpath-replacement-native"
> 
> "nativesdk-eglibc-initial" -> "autoconf-native"
> 
> "nativesdk-eglibc-initial" -> "automake-native"
> 
> "nativesdk-eglibc-initial" -> "libtool-native"
> 
> "nativesdk-eglibc-initial" -> "kconfig-frontends-native"
> 
> "nativesdk-eglibc-initial" -> "gnu-config-native"
> 
>  
> 
>  
> 
> So as long as there is no port for mingw32/Cygwin we are blocked. Any ideas?
> 
>  
> 
> Thanks,
> 
> Krzysztof
> 
>  
> 
> From: Francois Retief [mailto:fgretief@gmail.com] 
> Sent: Friday, August 09, 2013 6:33 PM
> 
> 
> To: Sywula, Krzysztof M
> Subject: Re: Yocto toolchain for Windows
> 
>  
> 
> Hi Krzysztof,
> 
> Yup, that is the same point where I am stuck at the moment. I sent an email to oe-core mailing list about this issue.
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082509.html
> 
> Hoping for a response from the OE community soon.
> 
> Cheers,
> 
>   Francois
> 
>  
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Type: text/html, Size: 21993 bytes --]

Re: Yocto toolchain for Windows

[Richard Purdie]

On Tue, 2013-08-13 at 09:17 -0700, Khem Raj wrote:
> On Aug 12, 2013, at 6:34 AM, Francois Retief <fgretief@gmail.com>
> wrote:

> > My understanding is that MinGW is the libc library for Win32
> > environments. So we need to "replace" eglibc with mingw for all code
> > that execute on the Win32 platform.  In the case of OpenEmbedded, it
> > is all packages that start with "nativesdk-" when is
> > SDKMACHINE="x86_64-mingw32".
> > 
> > 
> > Over the weekend I worked on this by disabling the eglibc recipes
> > and seeing what packages are missing.  The eglibc recipe provides
> > the "virtual/nativesdk-libc" package. My understanding is that this
> > virtual package must be implemented by MingGW.  In the process I
> > also found that pthreads-win32 was needed and added a recipe for
> > this.
>
> 
> Not really but if you stub eglibc from nativesdk out then make sure
> the host libc is plugged in correctly at all places where its
> expected. Its safer to let it
> build its own nativesdk eglibc. Since we also modify the shared
> library load paths in dynamic linker to use own nativesdk libraries
> first if available

Think about this for a second Khem - we're building a gcc which will run
on windows. Having a nativesdk-eglibc is therefore not desirable or even
possible, we need the mingw runtime instead.

I looked into this and NLS is enabled for nativesdk so it was trying to
build eglibc for libiconv and libintl. I've hacks on my branch to force
NLS off and use the libs as uclibc does. The takeaway of this is we
really need to make NLS properly configurable for nativesdk and then
this becomes much easier to solve.

I pushed some updates onto my branch and meta-toolchain now builds a
nice looking SDK tarball with ipk packaging, rpm for some reason has
missing files (some problem with smart). Whether the compiler there
works or is useful on windows I have no idea.

I've probably done all I plan to do with this which was really a bit of
fun for me to prove what is/is not possible. I'd be interested if anyone
tries using it though.

Cheers,

Richard

Re: Yocto toolchain for Windows

[Khem Raj]

On Aug 13, 2013, at 1:11 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2013-08-13 at 09:17 -0700, Khem Raj wrote:
>> On Aug 12, 2013, at 6:34 AM, Francois Retief <fgretief@gmail.com>
>> wrote:
> 
>>> My understanding is that MinGW is the libc library for Win32
>>> environments. So we need to "replace" eglibc with mingw for all code
>>> that execute on the Win32 platform.  In the case of OpenEmbedded, it
>>> is all packages that start with "nativesdk-" when is
>>> SDKMACHINE="x86_64-mingw32".
>>> 
>>> 
>>> Over the weekend I worked on this by disabling the eglibc recipes
>>> and seeing what packages are missing.  The eglibc recipe provides
>>> the "virtual/nativesdk-libc" package. My understanding is that this
>>> virtual package must be implemented by MingGW.  In the process I
>>> also found that pthreads-win32 was needed and added a recipe for
>>> this.
>> 
>> 
>> Not really but if you stub eglibc from nativesdk out then make sure
>> the host libc is plugged in correctly at all places where its
>> expected. Its safer to let it
>> build its own nativesdk eglibc. Since we also modify the shared
>> library load paths in dynamic linker to use own nativesdk libraries
>> first if available
> 
> Think about this for a second Khem - we're building a gcc which will run
> on windows. Having a nativesdk-eglibc is therefore not desirable or even
> possible, we need the mingw runtime instead.

Yes you are right. however I was thinking somehow mingw could run eglibc but now I realize I was
thinking more like cygwin env

> 
> I looked into this and NLS is enabled for nativesdk so it was trying to
> build eglibc for libiconv and libintl.

hmmm ok we have recipes for libiconv and proxy-libintl ( in meta-oe right now)
we can add nativesdk variants of them and then use the PREFERRED_PROVIDER magic


> I've hacks on my branch to force
> NLS off and use the libs as uclibc does. The takeaway of this is we
> really need to make NLS properly configurable for nativesdk and then
> this becomes much easier to solve.

that too.

> 
> I pushed some updates onto my branch and meta-toolchain now builds a
> nice looking SDK tarball with ipk packaging, rpm for some reason has
> missing files (some problem with smart). Whether the compiler there
> works or is useful on windows I have no idea.


cool will take a look at your branch

> 
> I've probably done all I plan to do with this which was really a bit of
> fun for me to prove what is/is not possible. I'd be interested if anyone
> tries using it though.

I think its a good addition to core. we should give it some soak time and pick
the bits may be for 1.6 timeframe.

> 
> Cheers,
> 
> Richard
> 

Re: Yocto toolchain for Windows

[Zhang, Jessica]

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

Hi Richard,

I've tried the sdk on windows and here're the issues that I've run into:

1. in our sysroot all the libraries have .so we need to change them to .dll
2. seems the cross compiler i586-poky-linux-gcc.exe relies on
libiconv-2.dll, so I manually installed that dll.
3. Now when I run i586-poky-linux-gcc.exe, I'm getting "the application was
unable to start correctly (0xc000007b). Click OK  to close the application."
By doing some initial search on the error, it seems relate to 32/64 bit dll
mismatch.  You mentioned that 32bit windows binaries are generated, so can
we generate a 64bit for me to try since my windows box is a 64bit.

Cheers,
Jessica

-----Original Message-----
From: openembedded-core-bounces@lists.openembedded.org
[mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
Richard Purdie
Sent: Tuesday, August 13, 2013 1:11 PM
To: Khem Raj
Cc: openembedded-core@lists.openembedded.org; Sywula, Krzysztof M
Subject: Re: [OE-core] Yocto toolchain for Windows

On Tue, 2013-08-13 at 09:17 -0700, Khem Raj wrote:
> On Aug 12, 2013, at 6:34 AM, Francois Retief <fgretief@gmail.com>
> wrote:

> > My understanding is that MinGW is the libc library for Win32 
> > environments. So we need to "replace" eglibc with mingw for all code 
> > that execute on the Win32 platform.  In the case of OpenEmbedded, it 
> > is all packages that start with "nativesdk-" when is 
> > SDKMACHINE="x86_64-mingw32".
> > 
> > 
> > Over the weekend I worked on this by disabling the eglibc recipes 
> > and seeing what packages are missing.  The eglibc recipe provides 
> > the "virtual/nativesdk-libc" package. My understanding is that this 
> > virtual package must be implemented by MingGW.  In the process I 
> > also found that pthreads-win32 was needed and added a recipe for 
> > this.
>
> 
> Not really but if you stub eglibc from nativesdk out then make sure 
> the host libc is plugged in correctly at all places where its 
> expected. Its safer to let it build its own nativesdk eglibc. Since we 
> also modify the shared library load paths in dynamic linker to use own 
> nativesdk libraries first if available

Think about this for a second Khem - we're building a gcc which will run on
windows. Having a nativesdk-eglibc is therefore not desirable or even
possible, we need the mingw runtime instead.

I looked into this and NLS is enabled for nativesdk so it was trying to
build eglibc for libiconv and libintl. I've hacks on my branch to force NLS
off and use the libs as uclibc does. The takeaway of this is we really need
to make NLS properly configurable for nativesdk and then this becomes much
easier to solve.

I pushed some updates onto my branch and meta-toolchain now builds a nice
looking SDK tarball with ipk packaging, rpm for some reason has missing
files (some problem with smart). Whether the compiler there works or is
useful on windows I have no idea.

I've probably done all I plan to do with this which was really a bit of fun
for me to prove what is/is not possible. I'd be interested if anyone tries
using it though.

Cheers,

Richard

_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 9626 bytes --]

Re: Yocto toolchain for Windows

[Richard Purdie]

On Wed, 2013-08-14 at 00:00 +0000, Zhang, Jessica wrote:
> Hi Richard,
> 
> I've tried the sdk on windows and here're the issues that I've run into:
> 
> 1. in our sysroot all the libraries have .so we need to change them to .dll

Which sysroot? The one for the target system should be using .so's since
we're targeting a Linux system.

> 2. seems the cross compiler i586-poky-linux-gcc.exe relies on
> libiconv-2.dll, so I manually installed that dll.

No surprise since the dynamic linking detection doesn't work for
windows. We can add a manual dependency to resolve that.

> 3. Now when I run i586-poky-linux-gcc.exe, I'm getting "the application was
> unable to start correctly (0xc000007b). Click OK  to close the application."
> By doing some initial search on the error, it seems relate to 32/64 bit dll
> mismatch.  You mentioned that 32bit windows binaries are generated, so can
> we generate a 64bit for me to try since my windows box is a 64bit.

I was confused, they are supposed to be windows 64 bit binaries (and
file under Linux says they are) so something other than what I
originally thought is wrong.

Cheers,

Richard