I have no idea why, but the installed "sed" wrapper never terminates
on RHEL. If I don't use the wrappen the the tools build fine, so this
just uses the already set autoconf variables to attempt to determine
if the system sed/awk are gsed/gawk and if they are then this avoids
using the wrappers.
There's a few oddities here:
* I have no idea why the sed wrapper fails, as it seems super safe.
* I haven't run into any awk problems, but I figured I'd treat it the
same as it isn't any harder.
* We shouldn't have to support 10 year old distributions.
Hopefully this doesn't break anyone's builds...
Some systems don't have things like GMP, MPFR, and friends installed.
Rather than requiring them to be installed as root, this uses a bit of
GCC's built-in functionality to download these libraries and build
them along with GCC.
This allows the tools to build on Red Hat, but only if you install
newer host tools (I have GCC, make, and texinfo).
I've been getting sporadic binutils build failures for a while that
all look something like
.../src/binutils/bfd/cpu-riscv.c:51:5: error: ‘bfd_arch_riscv’ undeclared here (not in a function)
bfd_arch_riscv, \
^
...
Makefile:1605: recipe for target 'cpu-riscv.lo' failed
make[6]: *** [cpu-riscv.lo] Error 1
make[6]: *** Waiting for unfinished jobs....
I belive the problem here is that "bfd.h" is in the middle of being
generated while this build step is being run. This can happen because
of a missing dependency, which you can verify by running
$ cd build-binutils-linux/bfd
$ rm stmp-bfd-h bfd.h cpu-riscv.lo
$ make cpu-riscv.lo
which will fail because "bfd.h" doesn't get regenerated. This patch
fixes that dependency problem by adding some RISC-V files to
ALL_MACHINES{,_CFILES}, which appears to be necessary to get the
dependency to work correctly (though I have no idea where it's coming
from).
It remains to be seen if this fixes the parellal build problem, but
this is certianly a bug.
buildbot.dabbelt.com recently failed because it was unable to fetch
the downloaded files fast enough because mirrors.kernel.org was being
slow. This patch allows me to cache the downloaded files somewhere to
avoid these sorts of network problems.
This should also be generally useful for other people who build the
toolchain regularly.
I thought this was a problem with the build, but it turns out that was
actually related to my bad (and now reverted) patch from earlier this
week.
Regardless, this is the canonical way to build a cross compiler so now
that it's done I don't see a reason not to use it.
We used to allow GCC to fail the stage1 build because it's impossible
to build the full GCC without glibc. This builds just the parts we
need ("all-gcc" and "all-target-libgcc") and then install them.
This should make build failures a bit easier to debug, as now nothing
should fail.
This reverts commit d3a771c5d1.
This breaks function calls on RV64. Since the warnings are benign
and MIPS does the same thing, I'm just reverting the commit.
I was sitting here watching GCC compile and noticed some warnings of
the form
operand . missing mode?
I'm not sure what exactly that means, but according to this GCC
mailing list post
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00825.html
they should be easy to fix. This patch follows that pattern, but I
really have no idea if I've done things correctly here. All I've done
is verify gcc-linux stage1 still builds, as I've got a bunch of other
diffs floating around that are currently breaking things.
Someone should make sure this still generates good code.
Wherever possible, rely on facilities native to GNU make rather than
invoke external utilities superfluously. Change the shell to /bin/sh
instead of bash since the latter's heftier feature set is unnecessary.
The -r option to cp(1) is marked obsolescent by POSIX; use -R instead.
Select between curl(1), wget(1), and ftp(1) through autoconf.
Wherever possible, automatically follow HTTP location redirects and
enable passive FTP mode.
Explicitly instruct tar(1) to read from stdin since this is far from
universal behavior if unspecified: The default file is /dev/sa0 in
FreeBSD, /dev/rst0 in NetBSD and OpenBSD, etc.
Tests for program presence, such as those formerly embedded in the
top-level Makefile for gawk and gsed, are better suited for autoconf.
Note that it is not sufficient to merely export AWK and SED environment
variables, as packages may still directly invoke awk(1) and sed(1) with
non-standard features independent of the autotools framework.
Wrapper scripts therefore remain necessary, although these are now
generated by the configure script to avoid hard-coded paths.
Do not assume the existence of /bin/bash on all systems.
Andrew Waterman
Andrew Waterman
Palmer Dabbelt
Palmer Dabbelt
Yunsup Lee
Darius Rad
Albert Ou