On Mon, 2013-08-12 at 19:51 +0100, Richard Purdie wrote: > On Fri, 2013-08-09 at 18:16 +0200, Francois Retief wrote: > > I am working on a MinGW SDK layer for OpenEmbedded. At this point, I > > got to the > > point where the "gcc-crosssdk" package builds successfully. > > > > My next target is to build the "nativesdk-libgcc" package. But the > > "nativesdk-eglibc-initial package" is getting in the way. As one can > > see from > > the log output below, eglibc, it complains that the mingw32 > > environment is not > > supported. > > > > So I switched TCLIBC in local.conf to "uclibc" in the hope that it > > would do better, > > but same error message. Same package gets built. > > > > Also there is a BitBake warning about multiple package that provides > > the same libc-for-gcc package. But when I run gcc-crosssdk, there is > > no such clash. > > > > Thus my question is, where does the eglibc package get included in the > > dependency > > tree? I worked through the package-depends.dot file to try and find > > what is > > referencing this package but with no luck.
I played a bit with this and shared some tweaks as: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/meta-mingw With those applied, "bitbake gcc-cross-canadian-i586 binutils-cross-canadian-i586 -k" results in: Summary: 6 tasks failed: virtual:nativesdk:/media/build1/poky/meta/recipes-core/zlib/zlib_1.2.8.bb, do_compile virtual:nativesdk:/media/build1/poky/meta/recipes-devtools/gcc/libgcc_4.8.bb, do_package [easy to fix, not blocking the build] /media/build1/poky/meta/recipes-devtools/libtool/nativesdk-libtool_2.4.2.bb, do_compile virtual:nativesdk:/media/build1/poky/meta/recipes-extended/bzip2/bzip2_1.0.6.bb, do_compile virtual:nativesdk:/media/build1/poky/meta/recipes-support/mpfr/mpfr_3.1.2.bb, do_configure [shared gmp lib is bust, --disable-shared might make mpfr build] virtual:nativesdk:/media/build1/poky/meta/recipes-core/gettext/gettext_0.18.2.bb, do_compile which is progress I guess. I've commented on a couple of the failures, I've not looked at the others. zlib is probably the one to get building next. The root cause was the libintl/libiconv providers being problematic. I've hacked those for now to make the build work, we can worry about sorting proper providers later should that be an issue. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
