[OE-core] Yocto toolchain for Windows

[Zhang, Jessica]

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 at lists.openembedded.org
[mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
Richard Purdie
Sent: Tuesday, August 13, 2013 1:11 PM
To: Khem Raj
Cc: openembedded-core at 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 at 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 at lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9626 bytes
Desc: not available
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130814/417585c9/attachment-0002.p7s>