Support building cross compilers #177

angerman · 2016-01-17T03:23:00Z

We basically need to build the stage1 compiler and then build
all the libs using the stage1 compiler, but we do not need to
build the stage2 compiler, as the stage2 compiler would run
on the target, which we do not intend to do.

The text was updated successfully, but these errors were encountered:

angerman · 2016-01-17T03:32:04Z

The relevant wiki items are:

thomie · 2016-01-17T10:25:51Z

See also these Notes in mk/config.mk.in:

Note CrossCompiling vs Stage1Only
Note Stage1Only vs stage=1

And from the toplevel ghc.mk file:

Note No stage2 packages when CrossCompiling or Stage1Only

angerman · 2016-01-17T11:11:12Z

@thomie thanks so much for adding the links.

first of all, ghc-stage1 can't use stage0's ghc library (it's too old)

(from the ghc.mk)

Makes me wonder if one might want to explicitly tell the build that one is using the exactly same version to build the cross compiler. E.g. say you build a full stage2 compiler from source and use that to build the cross compiler. In that case, I don't see why one could not use stage0's ghc library. Of course in the general case, it's too old.

ggreif · 2016-01-17T13:48:29Z

I guess that looking at the GIT commit should be enough to decide it.

Em domingo, 17 de janeiro de 2016, Moritz Angermann <
[email protected]> escreveu:

@thomie https://github.com/thomie thanks so much for adding the links.

first of all, ghc-stage1 can't use stage0's ghc library (it's too old)

Makes me wonder if one might want to explicitly tell the build that one is
using the exactly same version to build the cross compiler. E.g. say you
build a full stage2 compiler from source and use that to build the cross
compiler. In that case, I don't see why one could not use stage0's ghc
library. Of course in the general case, it's too old.

—
Reply to this email directly or view it on GitHub
#177 (comment)
.

kgardas · 2016-01-17T17:48:52Z

For porting GHC it's also very good to have an option to build stage2 compiler while cross-compiling. You will then be theoretically able to move ghc-stage2 to the target platform and use it as a native compiler...

angerman · 2016-01-18T02:47:03Z

@kgardas for porting certainly. But technically I don't consider a stage2 compiler a cross compiler anymore, as it targets the same platform it runs on.

izgzhen · 2017-06-28T15:39:32Z

Tried a few times but never succeeded in building GHC target=arm-linux-gnueabi for ghc-8.2 on Ubuntu 16.04.2 LTS, LLVM 4.0.

Stuck:

"inplace/bin/ghc-stage1" -static -O0 -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
/tmp/ghc858_0/ghc_8.s: Assembler messages:

/tmp/ghc858_0/ghc_8.s:41:0: error:
     Error: selected processor does not support `ldrd r0,r1,[r3,#64]' in ARM mode
   |
41 |         ldrd    r0, r1, [r3, #64]
   | ^

which is similar to https://ghc.haskell.org/trac/ghc/ticket/11058

Also tried lower versions, but failed for some other confusing reasons.

@bgamari @angerman Is there any suggestion what cross-compile setup for HEAD ghc would be an ideal choice for reference implementation?

Ericson2314 · 2017-06-28T19:08:03Z

@izgzhen That looks like with GCC. You need a -marmv7-a or similar to get at all the registers.

izgzhen · 2017-06-29T00:11:50Z

Added a -optc-march=armv7-a but its doesn't really work.

"inplace/bin/ghc-stage1" -static -optc-march=armv7-a -O0 -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o

Tried adding -optc-marm as well, not working in the same way.

If I add -optc-march=armv7, the error is different:

rts/StgStartup.cmm:1:0: error:
     error: target CPU does not support ARM mode

Ericson2314 · 2017-06-29T00:21:22Z

@izgzhen so I was working with Nix, and I just modified the shell script wrapping gcc to include the flag. I think the key difference here is that made sure that the flag always got to the gcc targeting the target platform, and never to the "build cc" gcc targeting the host platform. My guess is your second error is that latter gcc being confused.

izgzhen · 2017-06-29T01:19:09Z

Hmm...so you wrapped <target>-gcc with additional -m flag?

But this doesn't quite work for me. I think my ghc-stage1 did invoke the right <target>-gcc with -march=armv7 added, but still it said:

error: target CPU does not support ARM mode

Ericson2314 · 2017-06-29T01:50:46Z

Odd. Perhaps your tool chain actually was built targeting different 32-bit arm variant?

izgzhen · 2017-06-29T08:28:14Z

Aha, I found it. Grepping give me ("target arch", "ArchARM {armISA = ARMv5, armISAExt = [], armABI = SOFT}"), in settings, so I tried -march=armv5, -march=armv5e, -march=armv5t and -march=armv5te (info from <target>-gcc --help=target. The last one works.

izgzhen · 2017-06-29T08:30:35Z

I have no idea why my arm-linux-gnueabi-gcc-4.7 choose this though..

Ericson2314 · 2017-06-29T14:11:18Z

Try putting armv7a (no dash now) in the triple.

izgzhen · 2017-06-29T23:50:13Z

Still not working: I added several wrapper like below:

cat $(which armv7a-linux-gnueabi-gcc) 
#!/bin/bash
/usr/bin/arm-linux-gnueabi-gcc-4.7 -march=armv7-a $@

and ./configure --target=armv7a-linux-gnueabi --with-ld=arm-linux-gnueabi-gcc-ld --with-ld.gold=arm-linux-gnueabi-ld.gold --with-nm=arm-linux-gnueabi-nm --with-ar=arm-linux-gnueabi-ar --with-ranlib=arm-linux-gnueabi-ranlib. But compiling the RTS again gives me error:

"inplace/bin/ghc-stage1" -optc-std=gnu99 -optc-marm -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DUSE_LIBFFI_FOR_ADJUSTORS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-w -static  -O0 -H64m -Wall   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/StgCRun.c -o rts/dist/build/StgCRun.o
/tmp/ghc11814_0/ghc_1.s: Assembler messages:

/tmp/ghc11814_0/ghc_1.s:43:0: error:
     Error: selected processor does not support `vstmdb sp!,{d8-d11}' in ARM mode
   |
43 |         vstmdb sp!, {d8-d11}
   | ^

/tmp/ghc11814_0/ghc_1.s:52:0: error:
     Error: selected processor does not support `vldmia sp!,{d8-d11}' in ARM mode
   |
52 |         vldmia sp!, {d8-d11}
   | ^

izgzhen · 2017-06-30T17:21:42Z

Solved the vldmia ... adding -mfloat-abi=hard can solve this since somehow my settings showed that

("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = SOFT}")

And according to GCC ARM options:

-mfloat-abi=name
Specifies which floating-point ABI to use. Permissible values are: ‘soft’, ‘softfp’ and ‘hard’.

Specifying ‘soft’ causes GCC to generate output containing library calls for floating-point operations. ‘softfp’ allows the generation of code using hardware floating-point instructions, but still uses the soft-float calling conventions. ‘hard’ allows generation of floating-point instructions and uses FPU-specific calling conventions.

The default depends on the specific target configuration. Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries.

izgzhen · 2017-06-30T17:34:00Z

I believe the previously failed *.s is generated -- then since before that ARM_ABI is SOFT, why a non-supported instruction is generated?

bgamari · 2017-06-30T18:16:38Z

I suspect you need to instead pass --target=armv7a-linux-gnueabihf. Note the "hf" at the end; it stands for "hard float".

bgamari · 2017-07-07T02:42:07Z

Being curious, I just tried ./configure --target=arm7-linux-gnueabihf; hadrian on GHC HEAD. It managed to build the ghc library but ultimately failed with,

/-------------------------------------------------------------------------\
| Run Ghc LinkHs Stage0 (stage = Stage0, package = check-api-annotations) |
|      input: _build/stage0/utils/check-api-annotations/Main.o            |
|  => output: inplace/bin/check-api-annotations                           |
\-------------------------------------------------------------------------/
/mnt/work/ghc/ghc/_build/stage0/compiler/libHSghc-8.3.a: error adding symbols: Archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
shakeArgsWith     0.000s    0%                           
Function shake    0.323s    0%                           
Database read     1.360s    0%                           
With database     0.097s    0%                           
Running rules  1294.374s   99%  =========================
Total          1296.154s  100%                           
Error when running Shake build system:
* inplace/bin/check-api-annotations
user error (Development.Shake.cmd, system command failed
Command: /mnt/work/ghc/roots/8.0.2/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db /mnt/work/ghc/ghc/_build/stage0/bootstrapping.conf' '-package-id base-4.9.1.0' '-package-id containers-0.5.7.1' '-package-id Cabal-2.0.0.0' '-package-id directory-1.3.0.0' '-package-id ghc-8.3' -i -i_build/stage0/utils/check-api-annotations -i_build/stage0/utils/check-api-annotations/build/check-api-annotations/autogen -iutils/check-api-annotations/. -Iincludes -I_build/generated -I_build/stage0/utils/check-api-annotations -I/mnt/work/ghc/ghc/compiler -I/mnt/work/ghc/ghc/compiler/parser -I/mnt/work/ghc/ghc/compiler/utils -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/process-1.4.3.0/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/directory-1.3.0.0/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/unix-2.7.2.1/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/time-1.6.0.1/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/bytestring-0.10.8.1/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/base-4.9.1.0/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/integer-gmp-1.0.0.1/include -I/mnt/work/ghc/roots/8.0.2/lib/ghc-8.0.2/include -I_build/generated -optc-I_build/generated -optP-include -optP_build/stage0/utils/check-api-annotations/build/check-api-annotations/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build/stage0/utils/check-api-annotations -hidir _build/stage0/utils/check-api-annotations -stubdir _build/stage0/utils/check-api-annotations -no-auto-link-packages -rtsopts _build/stage0/utils/check-api-annotations/Main.o -o inplace/bin/check-api-annotations -O -H32m -optc-Werror=unused-but-set-variable -optc-Wno-error=inline -Wall -XHaskell2010
Exit code: 1
Stderr:
/mnt/work/ghc/ghc/_build/stage0/compiler/libHSghc-8.3.a: error adding symbols: Archive has no index; run ranlib to add one
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)

It sounds like ranlib was never run on the libHSghc static archive.

bgamari · 2017-07-07T04:12:21Z

The above wasn't actually caused by a missing ranlib run; we use ar q to construct the archive and therefore generally don't need to run ranlib. Instead, this was caused by the wrong ar being used. See #350.

Ericson2314 · 2017-07-07T21:59:14Z

This applies to both build systems alike, but I now understand there are <TOOL>_FOR_TARGET semi-standard macros for autoconf, which could help disentangle things?

izgzhen · 2017-08-22T11:03:08Z

I've been hacking on this from time to time in the past month, but it turns out to be quite difficult to take care of. I'll keep working on this, but it might take longer than I initially anticipated.

The first problem is that after #380, the "size doesn't match" in #349 is not solved by that in fact. I compared and tweaked the command line arguments for a long time, but it never worked so well.

izgzhen · 2017-08-28T11:45:10Z

izgzhen · 2017-09-01T05:41:19Z

The above tidbits are all checked, and the remaining few issues are filed as described above.

I think we can close this issue now.

Cc @snowleopard

izgzhen · 2017-09-01T05:45:17Z

maybe after #410 is merged

snowleopard · 2017-09-01T19:40:17Z

@izgzhen Sounds good! Do close this after we merge #410.

izgzhen · 2017-09-11T17:15:46Z

I'll close it since #410 is done.

angerman added bug enhancement cross-compilation labels Jan 17, 2016

snowleopard added this to the ghc-quake milestone Jan 17, 2016

snowleopard mentioned this issue May 6, 2016

Minimum Viable Product for tree-tremble #239

Closed

4 tasks

izgzhen self-assigned this Jun 30, 2017

izgzhen mentioned this issue Jul 3, 2017

Implement Stage1Only #337

Closed

bgamari mentioned this issue Jul 7, 2017

Using CC to build C sources complicates cross-compilation #349

Closed

izgzhen closed this as completed Sep 11, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support building cross compilers #177

Support building cross compilers #177

angerman commented Jan 17, 2016

angerman commented Jan 17, 2016

thomie commented Jan 17, 2016

angerman commented Jan 17, 2016

ggreif commented Jan 17, 2016

kgardas commented Jan 17, 2016

angerman commented Jan 18, 2016

izgzhen commented Jun 28, 2017 •

edited

Loading

Ericson2314 commented Jun 28, 2017 •

edited

Loading

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

izgzhen commented Jun 30, 2017

izgzhen commented Jun 30, 2017

bgamari commented Jun 30, 2017

bgamari commented Jul 7, 2017

bgamari commented Jul 7, 2017

Ericson2314 commented Jul 7, 2017

izgzhen commented Aug 22, 2017

izgzhen commented Aug 28, 2017 •

edited

Loading

izgzhen commented Sep 1, 2017

izgzhen commented Sep 1, 2017

snowleopard commented Sep 1, 2017

izgzhen commented Sep 11, 2017

Support building cross compilers #177

Support building cross compilers #177

Comments

angerman commented Jan 17, 2016

angerman commented Jan 17, 2016

thomie commented Jan 17, 2016

angerman commented Jan 17, 2016

ggreif commented Jan 17, 2016

kgardas commented Jan 17, 2016

angerman commented Jan 18, 2016

izgzhen commented Jun 28, 2017 • edited Loading

Ericson2314 commented Jun 28, 2017 • edited Loading

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

izgzhen commented Jun 29, 2017

Ericson2314 commented Jun 29, 2017

izgzhen commented Jun 29, 2017

izgzhen commented Jun 30, 2017

izgzhen commented Jun 30, 2017

bgamari commented Jun 30, 2017

bgamari commented Jul 7, 2017

bgamari commented Jul 7, 2017

Ericson2314 commented Jul 7, 2017

izgzhen commented Aug 22, 2017

izgzhen commented Aug 28, 2017 • edited Loading

izgzhen commented Sep 1, 2017

izgzhen commented Sep 1, 2017

snowleopard commented Sep 1, 2017

izgzhen commented Sep 11, 2017

izgzhen commented Jun 28, 2017 •

edited

Loading

Ericson2314 commented Jun 28, 2017 •

edited

Loading

izgzhen commented Aug 28, 2017 •

edited

Loading