Everyone‹ I¹m not sure where is the best place to take this question. Please excuse me, I¹m new.
I¹m struggling to build an OS X toolchain reliably and repeatably. I¹ve checked out the current top of the Œdylan¹ branch of Poky, meta-darwin, meta-intel and (for reasons I¹m not sure I understand) the OpenEmbedded meta-oe layer. I am not succeeding to build the OS X tool chain on my Linux VM running under Parallels (according to the arcane manual procedure required for using the MacOSX10.Y.sdk extracted from Xcode while respecting the Apple Xcode license) using SDKMACHINE=i386-darwin. An annoying failure, but I can work around it, is that the OpenDarwin cctools have a dependency on something that isn¹t reflected in the recipe, so you have to do repeated ³bitbake k² runs until it succeeds its do_configure method. I¹m not asking about that right now. The failure I have been struggling with is that ncurses-5.9 won¹t build for OS X. 1. The almost-stock ncurses-5.9 in the dylan branch has a known issue where if it is configured for darwin targets, the compiler is passed the ‹no-precomp-cpp option, which is deprecated. The GCC we are building in the cross toolchain for OS X doesn¹t support that option, so the configure script fails. 2. I tried to patch the ncurses recipe so that it applies the 2013-05-04 rollup patch from the FSF upstream, which contains the fix for the the ‹no-precomp-cpp option problem, but that doesn¹t work because GCC 4.7 isn¹t compatible with the C++ standard library headers in the OS X SDK (which are for a much older version of GCC that Apple still uses‹ for reasons, you all know them). I can¹t figure out why ncurses should even need to be build for the OS X hosted toolchain. This seems like an unnecessary dependency, and I don¹t see how to stop requiring it. Can anybody please help me turn off the requirement to build ncurses for deployment in the OS X toolchain when building with SDKMACHINE=*-darwin, please please please? Thanks. -- james woodyatt <james.woody...@intel.com> Software Architect, New Devices Group _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
