[OE-core] Yocto toolchain for Windows

Khem Raj raj.khem at gmail.com
Tue Aug 13 16:17:52 UTC 2013 

On Aug 12, 2013, at 6:34 AM, Francois Retief <fgretief at gmail.com> wrote:

> Hi Krzysztof,
> 
> 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

> 
> I ended up at a point where nativesdk-zlib is actually looking for libc and not finding it.  Currently I am trying to understand exactly what is required by "nativesdk-*" packages, and what mingw provides, in the hope of understanding where the mismatch is or where my understanding of the system breaks down.  ;-) 
> 
> Will keep you posted.
> 
> Cheers,
>   Francois
> 
> $ SDKMACHINE=x86_64-mingw32 bitbake nativesdk-zlib
> ...
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j2 -e MAKEFLAGS=
> | x86_64-oesdk-mingw32-gcc  --sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32 -shared -Wl,-soname,libz.so.1,--version-script,zlib.map -isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include -O2 -pipe  -fPIC -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo gzread.lo gzwrite.lo  -lc -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/lib -Wl,-O1 -L/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-rpath-link,/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-rpath,/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/lib -Wl,-O1
> | x86_64-oesdk-mingw32-gcc  --sysroot=/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32 -isystem/opt/tmp-eglibc/sysroots/x86_64-nativesdk-oesdk-mingw32/usr/local/oecore-x86_64/sysroots/x86_64-oesdk-mingw32/usr/include -O2 -pipe -o minigzip64 minigzip64.o -L. libz.a
> | /opt/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-oesdk-mingw32/gcc/x86_64-oesdk-mingw32/4.8.1/ld: cannot find -lc
> | collect2: error: ld returned 1 exit status
> | make: *** [libz.so.1.2.8] Error 1
> | make: *** Waiting for unfinished jobs....
> | ERROR: oe_runmake failed
> ...
> 
> 
> On 12 August 2013 12:13, Sywula, Krzysztof M <krzysztof.m.sywula at intel.com> wrote:
> Francois,
> 
> I tried compiling the same eglibc version as Yocto uses under mingw32/Cygwin. Apparently there is no port for these.
> 
>  
> 
> Mingw32:
> 
> $ ../eglibc-2.17/libc/configure
> 
> checking build system type... i686-pc-mingw32
> 
> checking host system type... i686-pc-mingw32
> 
> checking for gcc... gcc
> 
> checking for suffix of object files... o
> 
> checking whether we are using the GNU C compiler... yes
> 
> checking whether gcc accepts -g... yes
> 
> checking for gcc option to accept ISO C89... none needed
> 
> checking how to run the C preprocessor... gcc -E
> 
> checking for g++... g++
> 
> checking whether we are using the GNU C++ compiler... yes
> 
> checking whether g++ accepts -g... yes
> 
> checking for readelf... readelf
> 
> checking for sysdeps preconfigure fragments... x86_64
> 
> configure: running configure fragment for add-on libidn
> 
> configure: running configure fragment for add-on nptl
> 
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa
> 
> ia64 m68k mips powerpc tile
> 
> *** The GNU C library is currently not available for this platform.
> 
> *** So far nobody cared to port it and if there is no volunteer it
> 
> *** might never happen.  So, if you have interest to see glibc on
> 
> *** this platform visit
> 
> ***     http://www.gnu.org/software/libc/porting.html
> 
> *** and join the group of porters
> 
>  
> 
> Cygwin:
> 
> $ ../eglibc-2.17/libc/configure
> 
> checking build system type... i686-pc-cygwin
> 
> checking host system type... i686-pc-cygwin
> 
> checking for gcc... gcc
> 
> checking for suffix of object files... o
> 
> checking whether we are using the GNU C compiler... yes
> 
> checking whether gcc accepts -g... yes
> 
> checking for gcc option to accept ISO C89... none needed
> 
> checking how to run the C preprocessor... gcc -E
> 
> checking for g++... g++
> 
> checking whether we are using the GNU C++ compiler... yes
> 
> checking whether g++ accepts -g... yes
> 
> checking for readelf... readelf
> 
> checking for sysdeps preconfigure fragments... x86_64
> 
> configure: running configure fragment for add-on libidn
> 
> configure: running configure fragment for add-on nptl
> 
> checking add-on ports for preconfigure fragments... aarch64 alpha am33 arm hppa ia64 m68k mips powerpc tile
> 
> *** The GNU C library is currently not available for this platform.
> 
> *** So far nobody cared to port it and if there is no volunteer it
> 
> *** might never happen.  So, if you have interest to see glibc on
> 
> *** this platform visit
> 
> ***     http://www.gnu.org/software/libc/porting.html
> 
> *** and join the group of porters
> 
>  
> 
>  
> 
> To see why is eglibc needed do:
> 
> bitbake <recipe> -c populate_sdk –g
> 
> and:
> 
> less package-depends.dot
> 
>  
> 
> That’s what it gives:
> 
> "nativesdk-eglibc-initial" [label="nativesdk-eglibc-initial :2.17-r3\nvirtual:nativesdk:/build/kmsywula
> 
> 3/poky/meta/recipes-core/eglibc/eglibc-initial_2.17.bb"]
> 
> "nativesdk-eglibc-initial" -> "virtual/x86_64-pokysdk-mingw32-gcc-initial-crosssdk"
> 
> "nativesdk-eglibc-initial" -> "nativesdk-linux-libc-headers"
> 
> "nativesdk-eglibc-initial" -> "chrpath-replacement-native"
> 
> "nativesdk-eglibc-initial" -> "autoconf-native"
> 
> "nativesdk-eglibc-initial" -> "automake-native"
> 
> "nativesdk-eglibc-initial" -> "libtool-native"
> 
> "nativesdk-eglibc-initial" -> "kconfig-frontends-native"
> 
> "nativesdk-eglibc-initial" -> "gnu-config-native"
> 
>  
> 
>  
> 
> So as long as there is no port for mingw32/Cygwin we are blocked. Any ideas?
> 
>  
> 
> Thanks,
> 
> Krzysztof
> 
>  
> 
> From: Francois Retief [mailto:fgretief at gmail.com] 
> Sent: Friday, August 09, 2013 6:33 PM
> 
> 
> To: Sywula, Krzysztof M
> Subject: Re: Yocto toolchain for Windows
> 
>  
> 
> Hi Krzysztof,
> 
> Yup, that is the same point where I am stuck at the moment. I sent an email to oe-core mailing list about this issue.
> 
> http://lists.openembedded.org/pipermail/openembedded-core/2013-August/082509.html
> 
> Hoping for a response from the OE community soon.
> 
> Cheers,
> 
>   Francois
> 
>  
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130813/c52cbddd/attachment-0002.html>

More information about the Openembedded-core mailing list