| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
This fixes certain older GCCs which do not accept link options when assembling or compiling:
ppc_85xx-gcc: --hash-size=31: linker input file unused because linking not done
ppc_85xx-gcc: --reduce-memory-overheads: linker input file unused because linking not done
and diagnose this to stderr.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have two cases:
1. building a cross-compiler
2. compiling GHC to run on a foreign platform
These two are done with almost the same setup: (1) is the stage 1
compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
The only difference between (1) and (2) is that you if you set up the
build for (1), then it stops before stage 2 and you can 'make install'
to install stage 1.
Unfortunately, (2) didn't work, and the build system code needed some
tidying up.
Change to the way the build is set up:
Before
------
To build a cross-compiler:
./configure --target=<..>
To compile a foreign GHC:
./configure --host=<..> --target=<..>
Now
---
To build a cross-compiler:
./configure --target=<..>
And set "Stage1Only=YES" in mk/build.mk
To compile a foreign GHC:
./configure --target=<..>
|
|
|
|
|
|
| |
To explicitly choose whether you want an unregisterised build you now
need to use the "--enable-unregisterised"/"--disable-unregisterised"
configure flags.
|
|
|
|
| |
Related to #4862
|
|
|
|
| |
They were getting baked into Config.hs before.
|
|
|
|
|
| |
We want to use the inplace ar, rather than whichever ar the
machine that we build on happens to have.
|
|
|
|
| |
Patch from Karel Gardas!
|
|
|
|
|
| |
Now target32bit works for all targets without any manual intervention,
as it should do. #5735 was a portability regression.
|
|
|
|
| |
.ident directives are usually ignored by as(1), and in some cases (like Darwin/PPC) they even raise an error.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
This is a little cleaner, and removes a barrier to cross-compiling
to/from Windows. There are a few more tools that still need to be
handled in the same way.
|
| |
|
|
|
|
|
|
| |
I've made cpp_args include gcc_args. It effectively didn't before,
but seeing as gcc_args sometimes has -D flags in, I think doing so
is the right thing to do.
|
| |
|
|
|
|
|
| |
Makes it consistent with the existing "C compiler flags"
field.
|
|
|
|
| |
They were hardcoded in Config.hs
|
|
|