On Aug 13, 2013, at 1:11 PM, Richard Purdie <[email protected]> wrote:
> On Tue, 2013-08-13 at 09:17 -0700, Khem Raj wrote: >> On Aug 12, 2013, at 6:34 AM, Francois Retief <[email protected]> >> 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 > _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
