[OE-core] [meta-mingw] eglibc-initial package getting in the way

[Richard Purdie]

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