Bernard de la Paz writes:

I try to cross-compile GHC 8.0.1 with x86_64-mingw toolchain (gcc 6.2.1) and native GHC 8.0.1. Sources are from http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-src.tar.xz

cp mk/build.mk.example mk/build.mk

sed -i '1iBuildFlavour = perf' mk/build.mk sed -i '1iStage1Only = YES' mk/build.mk sed -i '1iHADDOCK_DOCS = NO' mk/build.mk ./configure --prefix=~/x86_64-mingw \ --target=x86_64-unknown-mingw32 \ --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc \ --with-ld=/usr/bin/x86_64-w64-mingw32-ld \ --with-nm=/usr/bin/x86_64-w64-mingw32-nm \ --with-ar=/usr/bin/x86_64-w64-mingw32-ar \ --with-ranlib=/usr/bin/x86_64-w64-mingw32-ranlib make -j8 install

First encountered error is in Types.hsc:

Types.hsc: In function ‘_hsc2hs_test44’: Types.hsc:219:20: error: storage size of ‘test_array’ isn’t constant

In general it is helpful if you include a bit more context on where in the build these errors ocurred. Is this during the stage1 build or stage2? Just a few lines of the surrounding build output would be helpful.

There are testing scripts in utils/hsc2hs/CrossCodegen.hs that create such code:

void _hsc2hs_test44() { static int test_array[value]; ...

where 'value' is const int, that is forbidden by C standard. GCC older then 4.4 reject this code, but Clang doesn't (does with -pedantic-errors). But with-gcc=/usr/bin/x86_64-w64-mingw32-clang fails sooner, so it cannot help. So I compiled Types.hsc (and three others) with clang and go further.

Hmm, presumably it fails since the array in question is static? On looking into this I realized that apparently VLAs have been made optional in C11, so perhaps we should be more conservative in using them, especially in hsc2hs.

Second error:

rts/posix/GetTime.c:25:2: error: #error No implementation for getProcessCPUTime() available. #error No implementation for getProcessCPUTime() available.

In file there are such strings:

#if ! ((defined(HAVE_GETRUSAGE) && !irix_HOST_OS) || defined(HAVE_TIMES)) #error No implementation for getProcessCPUTime() available. #endif

Linux definitely hasn't such function, it's a part of Windows API.

getProcessCPUTime is a function provided by GHC's runtime system. I believe the issue here is that the build system (rts/ghc.mk) chooses which implementation to use based upon the host operating system. This seems wrong. Then again, if this is wrong I don't see how cross-compilation ever actually worked. Surely I'm missing something here. Cheers, - Ben

Bernard de la Paz wrote:

I try to cross-compile GHC 8.0.1 with x86_64-mingw toolchain (gcc 6.2.1) and native GHC 8.0.1. Sources are from http://downloads.haskell.org/~ghc/8.0.1/ghc-8.0.1-src.tar.xz cp mk/build.mk.example mk/build.mk sed -i '1iBuildFlavour = perf' mk/build.mk

I'm pretty sure you will have better results with build flavour 'quick-cross' or 'perf-cross'.

sed -i '1iStage1Only = YES' mk/build.mk sed -i '1iHADDOCK_DOCS = NO' mk/build.mk ./configure --prefix=~/x86_64-mingw \ --target=x86_64-unknown-mingw32 \      --with-gcc=/usr/bin/x86_64-w64-mingw32-gcc \     --with-ld=/usr/bin/x86_64-w64-mingw32-ld \     --with-nm=/usr/bin/x86_64-w64-mingw32-nm \     --with-ar=/usr/bin/x86_64-w64-mingw32-ar \     --with-ranlib=/usr/bin/x86_64-w64-mingw32-ranlib

It should be sufficient to just do: ./configure --target=x86_64-w64-mingw32 Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/