[OE-core] Yocto toolchain for Windows

[Khem Raj]

On Aug 13, 2013, at 1:11 PM, Richard Purdie <richard.purdie at 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 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.

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
>