The build process on Cygwin stops and says that C compiler cannot create executables when it tries to build mpc-1.0.2 as a prerequisite for cross-compiling gcc.
This happens during default build for Olinuxino-imx233 board.
The message in log is: "error while loading shared libraries: ?: cannot open shared object file: No such file or directory"
Clearly, building under Cygwin has basically never been tested, it's currently not part of the platforms we support, and we never had contributions around this. If you're interested in supporting running Buildroot on Cygwin, then you'll have to investigate the various issues, and contribute fixes back to the upstream Buildroot. None of the Buildroot core developers are using Buildroot on Cygwin today.
Ok, I toyed with a Win7 VM here, struggled to install it and install Cygwin. Running Buildroot git master indeed breaks for me. As it turns out, Cygwin is horribly broken, and there is no way we can even remotely support this... So, here's how it goes: - in Cygwin, it is customary to install libs at the same place executables are installed; - so, in Cygwin, libraries are searched in ${PATH}, as well as the usual other places; - the native compiler is linked with cygmpfr-4.dll; - we build and install mpfr (dependency of mpc) which install cygmpfr-4.dll in $(O)/host/usr/bin/cygmpfr-4.dll ; - we have $(O)/host/usr/bin is ${PATH} because, well, we need it, obviously... So, when we try to run the native compiler, it tries to run-time link with *our* cygmpfr.dll, not the system one. Bummer, it breaks... OK, did I say we're not gonna support that use-case? Better install a real Linux box; a VM might even be faster than Cygwin... Closing as WONTFIX.
I found the workaround: place original cygmpfr-4.dll (or link to it) to /usr/lib/gcc/i686-pc-cygwin/4.8.3 directory. Then the build process continues. Yann, Thomas, does the unsupported status of Cygwin mean that no bugs against this build configuration should be created? Or may I create them with workaround if I find one?
Well, the workaround is just that, and probably the build will just fail further on. And it's not just cygmpfr-4.dll that is at fault here: in my minimal Cygwin install, there are 101 DLLs in /bin and there is *no* DLL in /lib or /usr/lib. So you'd have problems one after the other anyway: after mpfr, that'll be mpc, and you'd have to move your host mpc DLL too. Then what? We can not tell people to break their host system (like, moving DLLs around) to be able to run Buildroot. Working around this problem the way you did is just not sustainable in the long run. Cygwin is broken, we can not run on Cygwin. So, no, I'm afraid we won't accept bug reports about running Cygwin. As I said previously: get yourself a Linux machine. A VM would do OK, and might even be faster than Cygwin.