[OE-core] Yocto toolchain for Windows

Richard Purdie richard.purdie at linuxfoundation.org
Tue Aug 13 20:11:03 UTC 2013


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




More information about the Openembedded-core mailing list