GCC build instruction recommend to bootstrap a native compiler first.
Not sure, when that is really necessary. A major version change seems
reasonable.
Change-Id: I80a9ec25739b7d33a1d1c7b4b2140d19d89a99ae
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16675
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Just add some helpers that show parts (major, major.minor) of the GCC
version to be built (buildcc_*) and of the host compiler (hostcc_*).
They will be used in follow-up commits.
Change-Id: I37c12ad1a2d08645f40a9f0f0a479c8d7cc3e127
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16674
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Also remove a dead line that checks for unknown options: We already let
`getopt` check that.
Change-Id: I0e829b266e192757d6e455ee4cc608315bb4b7be
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16681
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We accidentally checked the status of `eval` instead.
Change-Id: I1ba258944184ed707ed1f176e528d8266656cb59
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16680
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Looks like this never worked correctly: There are three argument formats
to GNU getopt and none of them matches what we fed it. The missing
double dash before the `set` arguments proves that we always called it
with parameters that `getopt` did NOT parse.
Change-Id: Ib8343976ef31774b18567a9fc9745a9f58dd287a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16679
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
As we support `getopt` versions that don't know long options, every
option arguments needs a short option.
Also add the long options `--urls` and `--nocolor` to the `getopt`
string.
Change-Id: I11c393c3d90c7a16cdda119594221c85f902ed40
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/16682
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I3e3973e1c47505718cf73435156104ab73680441
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16387
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are shells where the result of a command substitution is subject
to word splitting (e.g. dash when assigning a value inside an export
statement).
Change-Id: I70a5bc124af7ee621da2bdb4777f3eaba8adafbb
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/15820
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The checksum command might appear to be unpredictable only by
checking the OS. Just list the candidates, sorted by possibility.
Change-Id: Ia3f4f5f0f98ff47d322a4f70689cca0bd4fa79fa
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/11483
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I4af90fd2fcfb2a823f9e6b1e975c71581f0b55e9
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16164
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On some kind of terms (shell in emacs), the color-ctrl
letters don't work. The backspaces can not delete
correct number of letters. So we don't print color-ctrl
letters in loop.
Change-Id: I1f1729095e8968a9344ed9f1f278f7c78f7110e9
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: https://review.coreboot.org/16066
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Turned out that there are versions of the patch command that use the
left hand side path for new files created by a patch. This behavior is
incompatible with some of our patches. Stripping the topmost dir from
the path with -p1 helps.
While touching that line, I couldn't resist to drop a command
substituion (the `echo $patch`). It really shouldn't be necessary as the
path to the patch file is already expanded in the head of the for loop.
Change-Id: I95398605db6dd54a8b08d8bc84c6602edbea6e10
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/15908
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins)
When no CFLAGS are explicitly provided to it, the GMP configure script
will figure out the best optimization flags to use on its own. In
particular, it will setup the march, mfpu and mtune flags based on
hardware detection.
However, when CFLAGS are provided, they are used as-is and such
detection doesn't happen. When the march, mfpu and mtune flags are not
provided (which happens when GMP wasn't built already), not only will
related optimizations be disabled, but some code might not build because
of missing support. This happens with NEON instructions on ARMv7 hosts.
Thus, it is better not to set CFLAGS and leave it up to the GMP
configure script to get them right and still reuse those later.
Change-Id: I6ffcbac1298523d1b8ddf29a8bca1b00298828a7
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15452
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The binutils patch went in without updating the revision,
so we need to update it now. This was done in commit bcfa7ccb
(buildgcc: Update to binutils-2.26.1 & Fix aarch64 build issue)
Change-Id: Ifad4a2e3973f1f60d0ea840945e2bd097e1b4474
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15712
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
- Update to the latest version of GNU binutils
- Add a patch to undo the changes to binutils done by commit c1baaddf
so that arm-trusted-firmware builds correctly again.
Test: Build arm-trusted-firmware (ATF) with this patch. Build ATF
with binutils 2.26.1 changing the '.align x,0' to '.align x', which
changes the padding bytes to NOP instructions. Verify that everything
except the padding bytes is the same.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20364 for more
information about this issue.
Change-Id: I559c863c307b4146f8be8ab44b15c9c606555544
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15711
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Bootstrapping gcc is the recommended way if your host gcc's version
doesn't match the gcc version you're going to build. While a build
with an outdated host gcc usually succeeds, an outdated gnat seems
to be a bigger issue.
v3: Some library controversy: gcc likes the libraries it ships with
most but we don't want to install shared libraries. So we build
them static --disable-shared) and install only the minimum
(libgcc, libada, libstdc++). However, as the code of these
libraries might be used to build a shared library we have to
compile them with `-fPIC`.
v4: o Updated getopt strings.
o The workaround for clang (-fbracket-depth=1024) isn't needed
for bootstrapping and also breaks the build, as clang is only
used for the first stage in that case and gcc doesn't know
that option.
So far build tested with `make BUILDGCC_OPTIONS="-b -l c,ada"` on
o Ubuntu 14.04 "Trusty Tahr" (i386)
o Debian 8 "Jessie" (x86_64) (building python (-S) works too)
o current Arch Linux (x86_64)
o FreeBSD 10.3 (x86_64) (with gcc-aux package)
and with clang host compiler, thus C only: `make BUILDGCC_OPTIONS="-b"`
on
o Debian 8 "Jessie" (x86_64)
o FreeBSD 10.3 (x86_64)
v5: Rebased after toolchain updates to GCC 5.3.0 etc.
Build tested with `make BUILDGCC_OPTIONS="-b -l c,ada"` on
o Debian 8 "Jessie" (x86_64)
Change-Id: Icb47d3e9dbafc55737fbc3ce62a084fb9d5f359a
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/13473
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Refactor build() to make things more flexible:
Add a parameter that tells if we build a package for the host or for a
target architecture. This is just passed to the build_$package()
function and can be used later to take different steps in each case
(e.g. for bootstrapping a host gcc).
Move .success files into the destination directory. That way we can tell
that a package has been built even if the package build directory has
been removed.
Change-Id: I52a7245714a040d11f6e1ac8bdbff8057bb7f0a1
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/13471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Update gdb to 7.11 and expat to 2.1.1
riscv64-elf is still broken.
Change-Id: Id7605f4274fcb15f9c3e366f5c492328f70f7956
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14461
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
New tools:
* mpfr 3.1.4
* binutils 2.26
* gcc 5.3.0
* llvm/clang 3.8.0
Patch changes:
* binutils-2.25_fix-aarch64.patch: fixed in 2.26
* binutils-2.25_host-clang.patch: the positions of header file
includes have been adjusted
* binutils-2.25_no-bfd-doc.patch: update to 2.26
* binutils-2.25_riscv.patch: update from riscv-gnu-toolchain
* gcc-5.2.0_elf_biarch.patch: update to 5.3.0
* gcc-5.2.0_gnat.patch: update to 5.3.0
* gcc-5.2.0_libgcc.patch: update to 5.3.0
* gcc-5.2.0_nds32.patch: update to 5.3.0
* gcc-5.2.0_riscv.patch: update from riscv-gnu-toolchain
* cfe-3.7.1.src_frontend.patch: update to 3.8.0
In the latest code of riscv-gnu-toolchain project, the patch for
{binutils,gcc}/config.sub has been removed, and the target is renamed
as riscv32 and riscv64. The `riscv' to `riscv64' change in xcompile is
in another commit.
Test results:
All GCC and LLVM/clang toolchain build successfully.
x86,arm: qemu boots
power8: firmware fails to boot
aarch64,mips: not tested
riscv: firmware fails to build with new binutils
clang: firmware fails to boot
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Change-Id: I42ce89c29263d768d161c28199994f17d0389633
Reviewed-on: https://review.coreboot.org/14227
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Always set HOSTCFLAGS to the flags GMP was built with, defaulting to
"-Os" if it isn't built yet. Previously, if GMP was already built or
not even in the list of packages to be built, this was silently skipped
and other packages were built with empty HOSTCFLAGS.
Change-Id: I29b2ea75283410a6cea60dc1c92b87573aebfb34
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13550
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The xz archives are slightly smaller than the bz2 archives for gmp
and mpfr, so use them instead to speed up the download.
Change-Id: I3729455cdbc46e5a0cff119ecca97b0e00c3d402
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14462
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Both packages are not using the target architecture. Drop it,
and remove them from package_uses_targetarch
Change-Id: I58efde4cb7cc39e7e3c31527eb7682e318928100
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14464
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Store both the version number and git hash in the file name
when copying the buildgcc script to the destination directory.
Also, fix the quoting in the lines touched anyways, and move the
script to $TARGETDIR/share/
Change-Id: Ib37dc2be57ee7f0ae18a0b954f537f8b4c2db9d0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14347
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Many of the tools and libraries don't use a target architecture, but
they were still getting put in one. This change separates out the
builds that need the target architecture from the ones that don't,
and sets the build directory accordingly.
This will help keep from rebuilding the libraries when building all
of the tools if you keep the temporary files around (-t option).
Change-Id: Id6c17719332f2244657f103f5f07ca7812d51af1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14229
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
On certain versions of /bin/sh the following sequence
causes problems.
'$CC --version | grep clang &>/dev/null && ...'
The above is a bashish for 2>&1 >/dev/null. However, buildgcc
is interpeted by /bin/sh which doesn't necessarily mean bash.
On dash it's effectively forking grep off into the background
and always evaluating an empty statement to /dev/null while
unconditionally running whatever follows the &&.
Change-Id: Ie3a2ebb12226434d50a7b2a7e254c8b80ae4c46b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14281
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
On certain versions of /bin/sh assigning variables with spaces
unquoted leads to failures. Therefore, quote variables that
are known to be passed in that have spaces.
Change-Id: I007c56c3bfb8183bb4b16cf0591f6aa508fd105d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14280
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Otherwise, on OS X, some architectures will fail
to build libgcc (verified for ARM toolchain).
Change-Id: I8b58e0582596ad39cad92e9d478158c46a96a26e
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14256
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Most cross compilers fail to compile on systems with Clang being the
default compiler (OS X and some BSDs). Clang dislikes some of GCC's
autogenerated code. We also missed switching CFLAGS to CXXFLAGS when GCC
switched to C++ compilation per default.
Change-Id: I87caa1a15982c431048aa79748ea7ef655a9a3a1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14232
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add check_for_library routine to test for missing libraries.
- Add a check for zlib.
- Remove 'utility' text from please_install() routine since we can test
for libraries or utilities now.
- Remove incorrect 'solution' text from alternate install since I was
updating that line.
Change-Id: Id5ef28f8bde114cbf4e5a91fc119d42593ea6ab2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14147
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These are multi-threaded decompressors for .gz and .bz2 compressed
files. If they're installed, use them to decompress, if they're not,
use the standard single-threaded decompressors.
Change-Id: I397740817e6b234a43b62075899964bdab14f121
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14146
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a newline after the supported version text.
Move $TARGETDIR left so that longer paths print better.
Change-Id: If520e1b8657a526dee27763aee62cb78777d020d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is required on powerpc64 to build both little endian and big endian
libgcc.
Change-Id: I295c8ee5e8131d4108e98d1bfd53abb8bd8982b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/14163
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update IASL from 20150619 to 20160318
See release notes at acpica.org
Change-Id: Ic7e7b3956378ad611069e984d5a59c78e4cb08b1
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/12817
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Add powerpc64le-linux-gnu & nds32le-elf to the instructions as
supported architectures
- Add nds32le-elf as a supported architecture so it will stop warning
when you build it.
Change-Id: Ifcdbc3d082eae5b9b5f8828914e7d2b7ed1f13a4
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13961
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a comment to try to lower possible confusion later if the jenkins
tool builder fails to build a new tool. The URLs for the packages that
are downloaded are checked against known locations so that someone can't
maliciously download a package from somewhere and run it on the build
server. This provides a little bit of security, but could confuse
someone if they don't realize it.
Change-Id: I7858e3d86fc705b480f6792b6adf3d5349580e01
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13955
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Numerous changes have gone in since the last bump, let's increase
the version.
Change-Id: Ie3ae8c24b26bd22b70bc5ddf5c1125b5b1d3a021
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13873
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This should allow the builder to download the packages securely.
Change-Id: If5feeff85bd551cbe08849421197d11cc2432d1e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13867
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When writing to a logfile, the color codes just make things confusing.
The --nocolor option will allow these to not be printed.
Change-Id: I67645aac20b420ac83b828e77e0e50aab88d3d47
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13866
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
qemu-power8 wants to tell about itself with XML, and so
we need to build gdb with EXPAT so it can understand XML.
Change-Id: I460e27f883956ed5d54e6070916e2682ee0f7a1b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/13846
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Power 8 was once again having build issues. Adding --with-system-zlib
fixes them. It seems the builtin one is only needed when you are going
to build programs, and it falls apart in other cases.
Searching --with-system-zlib reveals this to be a very popular topic.
This has not broken other toolchain builds (for me); it should not for
anyone else. Then again, this is gcc, about which I need say no more.
Change-Id: Ica9d057d88982543b5dda471cc949c31fe15932f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/13700
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Apparently acpica-unix is shipped under
"A non-open source license (the 'Intel license')" while acpica-unix2
comes under GPLv2/BSD dual license. (see https://acpica.org/Licensing)
So go with unix2.
Change-Id: I412812187bbf488eb4ad6d7fb8d2840f2f5e06d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13686
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Make the gcc build system create multiple libgcc.a instances for
different ABIs.
Change-Id: I1c888bf751bf43566da8927ed0aedb53857363bf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13625
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not much testing, update mostly so we can test with the
latest scan-build.
Change-Id: I50d28b7e0dfd31f9ae565c8515d5ab1760ca4c62
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The compiler really supports a whole line of ARM CPUs, not just
ARMv7a:
arm-eabi-gcc: note: valid arguments to '-march=' are: armv2 armv2a
armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m
armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m
armv7-r armv7e-m armv7ve armv8-a armv8-a+crc iwmmxt iwmmxt2 native
So let's reflect this in the cross compiler name.
Change-Id: I717760d80954655b2de9ae019b813d81e9a75762
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13515
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It may still fail on non-Linux, and the compiler may do fancy things,
but it builds.
Change-Id: If3456f5fef8d01082a49978dc7cda5450f96f5cc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13416
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
GMP's configure tries to build for 64-bit with a 32-bit userspace on
NetBSD too. Help it by forcing ABI=32.
Change-Id: I290ea0ef1626fdd88dc3ff74fadb9578ef6a1c9c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13067
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This reverts commit 89798bcb0c.
Disable building gnat again as it turned out that many distros don't
ship with a sufficient recent version of gnat. We'll have to find a
reliable way to check for the installed gnat version and query the
user or bootstrap gcc in that case.
Change-Id: Ife7cf7c9d1567aca898ce308b120a7b9e146e5f5
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/13422
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
I thought we'd be using gnatmake but it's deprecated. Who needs it
anyway?
Change-Id: Ic08add72e771fa346c8a736ea901863ea5737d91
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of printing out a single tool that needs to be installed
each time buildgcc is run, print out the entire list of tools
to be installed, then halt.
Change-Id: I7761760eef3c45ba371f882a4f987408945bb3e5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12856
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously, when we tested for g++ and two different versions of clang,
if the earlier versions were not found, buildgcc would still request
that they be installed. This obviously isn't needed, and isn't the
desired outcome.
Now, if one of the first tests fails, nothing gets printed. If all
the tests fail, it tells you to install either g++ or clang.
Change-Id: I71359f59c4c6bee3c3c55e4e6105f11e6ca51527
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12852
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This reverts commit 68d0e4a5a1.
Special handling of MPFR is no longer needed with the latest
MPFR release.
Change-Id: I96d9ea92cfb74eed6af2ba62254f0678081e2b4f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12833
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current MPFR version contains a stale config.guess file
that requires special handling on ppc64el systems. Bump
the MPFR version to the latest release.
Change-Id: I5e86c732c09f8a6a43f9812452124d64d337ea3f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12832
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The config.guess file included with MPFR is completely obsolete,
leading to build failures on ppc64el due to the system architecture
not being detected. Regenerate the files from the host system via
automake before attempting to build MPFR.
Change-Id: I00fc16003906e373d112c25978197ac907adccfd
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12816
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The previous official GMP release (6.0.0) contains a bug that
prevents compilation on ppc64el systems. Increase version
to the latest version (6.1.0).
Bug details:
gcc build on ppc64el fails with:
(.text+0x4c): undefined reference to `BMOD_1_TO_MOD_1_THRESHOLD'
While I don't have an exact commit hash due to Hg use upstream,
a missing BMOD_1_TO_MOD_1_THRESHOLD define on ppc64el was quietly
fixed in Hg before the 6.1.0 release.
Change-Id: I1c05a1c194141db5f8522148c2e20e7558d34714
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12811
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
clang version now returns:
coreboot toolchain v1.33 November 25th, 2015 clang version 3.6.1
(tags/RELEASE_361/final) (based on LLVM 3.6.1)
Change-Id: I948d7f4d06c244987342cfc7d5c7e728cbed93bd
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12777
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the coreboot toolchain version to iasl's version output.
% ./xgcc/bin/iasl -v
Intel ACPI Component Architecture
ASL+ Optimizing Compiler version 20150619-64
Copyright (c) 2000 - 2015 Intel Corporation
coreboot toolchain v1.33 November 25th, 2015
This won't actually be checked until the next version of
iasl so that we don't have to rebuild again for no reason.
The buildgcc version was intentionally not incremented for
this minor change.
Change-Id: I03a1a777fdb84e34bfceb7b1eb43fffbc1f3a2fc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12688
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
By adding the version number of tools, we can help people keep up to
date with their tool versions. This will be used now to determine
whether the IASL version being used is the version supported by
coreboot.
Change-Id: I24a68b01c819871f90403869570125e71b96bd70
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12545
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Grep the output of wget, showing only the percentage.
Leave the final "100%" unerased.
Checking return code of wget is removed.
Change-Id: I4559e88d541738a594dce92e23589992f234cb9b
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11520
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As with most other languages, a pre-installed Ada toolchain is needed
to build gcc's Ada frontend. To support building with older host tool-
chains, the patch `gcc-5.2.0_gnat.patch` disables warnings for unknown
pragmas. Building has been tested with host gcc-4.9 and hopefully works
with newer versions, too.
For convenience, the gnattools (e.g. gnatmake etc.) will be build if
'ada' is specified as a target language.
Change-Id: Ia78c29d1aba2943de5238421a324cfff8eb08875
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add an option `--languages` which takes a list of target languages to
buildgcc. That list gets passed through to the configure step for
building gcc.
Also alter the Makefile to pass $(BUILD_LANGUAGES) to that option, if
this variable is set.
Change-Id: I6a74ab2c75871ea8d03a499cca33d88938b59c8d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/11589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ie3a44c6db9c9c186c52b4743334266ec5411ba8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I9f59a00e735f39df813b2216290da62eea3c595d
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11372
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Refactor the code to be better understandable.
Change-Id: Ia815a27f7cc83c226a32e87485d712a5fbf4168e
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11318
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
All compilers built, incl. x86_64-elf as multilib and riscv-elf.
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69372
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10975
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
1. Add -P|--package to build iasl
2. Remove -G|--skip-gdb, which was to skip gdb.
3. Add -S|--scripting to build gdb
4. Remove -C|--clang, which was to build clang.
All these changes are aligned with the options parsing below.
The help text is correct.
Change-Id: I897ea5e8ab002086e45bf05ff33230815b246057
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11158
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Similar to what the below change says,
(
http://review.coreboot.org/10792
commit ddb8f80894
Author: Patrick Georgi <patrick@georgi-clan.de>
Date: Sat Jul 4 17:45:54 2015 +0200
buildgcc: Deal with gmp on 32bit Linux on 64bit CPUs
GMP is overeager to detect 64bit ABIs even if the entire running codebase is
32bit (but on a 64bit CPU). Enforce a 32bit build in that situation.
)
building GMP can not detect Cygwin is 32bit either if the
host which Cygwin is running is 64bit. We set ABI=32
in that case.
Change-Id: Ic53d75defebbe902325eb07f3d8631b2a53245ef
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11123
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Running `uname` on Cygwin gets "CYGWIN_NT-6.1-WOW" instead of "Cygwin".
We need to fix the $UNAME on Cygwin.
Change-Id: I540bfc52089951006fd0e20bb9893a3d891df9e1
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11124
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It doesn't know "source", but wants the older "." instead
Change-Id: Iafa61b1d2ffc9c737ab67a417c62417593b69374
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10974
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In case of downloading errors, the URL is handy for analyzing the cause.
Change-Id: I6874cdc3c881cfdd52c80f80323536c30723654b
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10853
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Running "clang -target i386-elf --print-librt-file-name" prints
[..]/bin/../lib/clang/3.6.1/lib/libclang_rt.builtins-i386.a
However, the correct path is [..]/lib/linux/libclang_rt.builtins-i386.a
on a Linux host. Hence, create symbolic links to make sure that our
build system finds the file where it expects it.
Change-Id: I21ef5c4a690d83c326717ca55c5ace558257a0ec
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10815
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GMP is overeager to detect 64bit ABIs even if the entire running codebase is
32bit (but on a 64bit CPU). Enforce a 32bit build in that situation.
Change-Id: I23e9e57f3c8b0e3ad2e4e1e3eb106f7830aa76a1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10792
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
buildgcc fails if g++ or clang isn't found on the host. This
was failing on OSX due to the string used to check for clang
doesn't match "Apple LLVM". Add an additional search string for
clang "LLVM".
Change-Id: I05e36cfc690061b3233376d57f44f197cab933ea
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10569
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's a separate target -P iasl for that now.
Change-Id: I95c0fe8fc266859d8a31b7bea890775dc9f19694
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10567
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this change, the x86_64-elf-gcc can compile i386-elf
binaries by specifying -m32. The patch against GCC is needed
to enable building the 32bit libraries when building x86_64-elf-gcc
Change-Id: Ic86a009eccfdf3e33a398bcdcc13b15c8dfc0d31
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10497
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For consistency in user output, move the check for all
required utilities after printing the banner and parsing
options.
Change-Id: I5bf31368885c73e35f18b02d53d099f3f3871acc
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10566
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When required tools are missing, try to give the user more detailed
information on how to solve the problem.
Change-Id: Ifa21c1af38a036a7d4f5a786041a87a7d45f4ec5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10555
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves the CMAKE definition down into the case statement
for $PACKAGE so that it is only required when the user wants to
build clang.
With this approach, "./buildgcc -P clang" will error out with the
"ERROR: Missing tool:" message if cmake is not installed.
Change-Id: I1e5c1bd67ade8f93ba0390df7f234deb47b9b18a
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/10556
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The precise phrase returned by 'type' differs between locales and shells.
It also doesn't matter because it returns an error code when it hasn't found a
match.
Let's simply assume there's no build_$OneOfOurPackages commands around that
could also match.
Change-Id: I44f021243149701e8da9dd74c368ca2ad4509419
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Tested-on: linux bash, linux dash, solaris sh, solaris ksh.
Reviewed-on: http://review.coreboot.org/10517
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
using grep is an extra process invocation, but it's not a bashism.
Also match precisely, so AGCC doesn't trigger on GCC (we don't have collisions
right now, but we won't have to deal with them in the future)
Change-Id: I242833c350b7f1e6a6793f288c1aae0b50d57a26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10518
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Build with bfd and gold linker, but use bfd linker per default
and make sure that lto is enabled in both binutils and gcc
Change-Id: I0584396b4580674cfdca24fbed0d8eeb1ee38806
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10496
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Instead of building IASL and GDB implicitly when building
GCC, this patch changes buildgcc to let you explicitly specify
what you want to build.
This will prevent IASL from building over and over again, when
all you need is GDB.
The new command line option is -P | --package <package> where
package is one of the following: GCC, GDB, CLANG, IASL
If no package is specified, buildgcc will default to GCC.
Change-Id: I8836bed16fc2bc39e0951199143581cc6d71cb4d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10492
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
IASL was broken when compiling without GCC.
Change-Id: Ib859ce41c1dda10181781c025fc378504f5ebb91
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10495
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
GDB stopped building ever since we updated from version 7.6
but nobody noticed ;)
Update from 7.9 to 7.9.1 and bring the required patches forward.
Change-Id: I2f357525a46d5540e9f57b80d830943bbd5dfcaf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10494
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This groups all tasks happening in the main program,
orders them according to their dependencies and adds
comments on the various tasks.
Change-Id: Ib62bd213977cbc3307ef62e9a7e64515563968c1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10490
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
- don't capture build_$package in a subshell by piping it
- move HOSTCFLAGS to build_GMP
- only create a build directory if a build happens
- automatically collect packages to build
Change-Id: Ic5a9f3f222faecd3381b413e5f25dff87262a855
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10475
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
Bring gdb in sync with all other build targets.
Change-Id: I9c478947a00f044edf910a91d876bbf486a791cf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10488
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Otherwise one could end up with what they think is a coreboot toolchain
but in fact it'd be missing some patches.
Change-Id: Ic451f7061b822d0f4b64acc9976ba81fd544e85b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10487
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
gcc and binutils fixed their upstream tar balls, and running
autoconf created more problems than it solved
Change-Id: I0003dd597f521701405ff35923214435136b262d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10486
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I29fe23e377045f08b8212742d84c2ee2b4a61b15
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10485
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I7a095470d408d013a4a915e010c59ea99ca1f1c8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10484
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
This removes quite a bit of boilerplate from the script, and makes
it easier to read.
Change-Id: I92348b810ff19f7d18810f842b76e0e595b3d397
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a new option -C|--clang to buildgcc to build a clang based
toolchain as opposed to a gcc based toolchain. This toolchain
comes with the required patches needed to successfully build
coreboot, and also with clang's famous scan-build script.
Change-Id: I1aea7cd6002edc4f3bb2b46dc1f69a212ad18f77
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10415
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- keep a list of packages to build in $PACKAGES and only download,
patch and build a package if it is in that list (instead of having
exceptions for GDB, EXPAT and PYTHON)
- unify interface for download() and unpack_and_patch()
- consolidate some randomly spread code like creating / removing
build directories and calls to searchtool()
Change-Id: I2070e3b2fbb84eb18e9220658fb2d5518b8179ee
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10434
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will be useful for adding clang support (and hopefully
makes the code a bit more readable)
Change-Id: Ie866fb2bd71e2a64f26f2755961bd126e101cbe5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
crossgcc builds gmp, whose build system normally optimises for the hardware
it's built on. That may give a minor performance boost but has the downside
that the compiler becomes non-portable and may break on other systems due to
illegal instructions.
Setting CFLAGS to some reasonable value prevents gmp's configure script from
choosing CPU specific -mtune flags (which may enable optimizations that only
run on CPUs with the same feature set).
Enabling "fat" builds make the build system add all optimized assembler
routines and makes the selection of the right one a runtime decision instead
of deciding at compile time.
Change-Id: I72d20627270baa082cd02ebb4c9a09cd23f30f8c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10412
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
If the buildgcc is interrupt by Ctrl-C, probably part of
an archive is downloaded. If we run buildgcc again, the
incomplete archive would be considered as cached file
and skipped.
We check file hashes to see if the file is complete. If test
is failed, we need to delete the partially-downloaded file
and download it again.
sha1sum is quite different among the distributions.
Only Linux, Cygwin, Darwin have been tested.
Once new archive is deployed, a new checksum would be created,
which should be uploaded along with the script buildgcc.
Change-Id: Ibb1aa25a0374f774e1e643fe5e698de7bf7cc418
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4511
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
People were confused about the 'missing toolchain', so
improve the error message.
Change-Id: Icaee338aeedce2255bcfdafe5407c9df02ad9c4a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10036
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Since FreeBSD doesn't have libdl, these errors are shown:
- config.log: /usr/bin/ld: cannot find -ldl
- crossgcc-build.log: configure: error: C compiler cannot create executables
Conditionally pass the presence of libdl in LDFLAGS.
Change-Id: I79c48da7e6700a4606c9e0c1314241db8997d3f3
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/2342
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
No need to enforce GNU versions for them.
Change-Id: Ieeb43298331fbefbcc1e230d41a90e9df56993eb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10017
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
bzip2 --version |grep -c will wait for input on stdin. ./buildgcc will hang because of this.
Add `cat /dev/null |` close the stdin.
Change-Id: I2a8b08a4d90ca7a89705923d5b68ba6ac13f29b3
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9605
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Copy $0 contains the path, and we cd into that early.
Change-Id: If4124d16dea97b5eee4996bdfa3eae3d5d94c5d1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9145
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of repeating the ok/failed test all the time,
move it into a function.
Change-Id: I7496dfb5d3d2385316c577e1cf0901950b0e7083
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8987
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The first problem for crossgcc users that encounter build errors is
figuring out what is wrong with the build. Point out where the logs
reside.
Change-Id: I0300ecf6356c1a4ce18ae1e37fe0a56f46210d13
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/8982
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ie002c69ab23cfc961b77771c4f2c20e5ae6bea60
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8633
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We use paths relative to that in the buildgcc script.
Change-Id: I2b79c3d2c75088af7e8e362d18a38274352eb965
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/8713
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
You can build your new toolchain with:
$ cd util/crossgcc/
$ ./buildgcc -d /opt/cross -p x86_64-elf -j 16
or
$ make crossgcc-x64
Change-Id: I8eb584166294578d2b33c63e94ed3aca9b5de4f4
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/8668
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
GCC's build system is sometimes confused by our build system's
configuration: make crossgcc failed, while
util/crossgcc/buildgcc -p armv7-a-eabi didn't.
Make sure the GCC build system runs independently from
ours by breaking any ties.
Change-Id: I563e17b22127bc8c83ebfb17252184a3b6e0e58b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/8545
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The following changes are included.
Changes in version 1.0.3:
- Fixed mpc_pow, see
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2014-October/001315.html
- #18257: Switched to libtool 2.4.5.
Changes in version 1.0.2:
- Fixed mpc_atan, mpc_atanh for (+-0, +-1), see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994#c7
- Fixed mpc_log10 for purely imaginary argument, see
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2012-September/001208.html
Upgrading also fixes the issue, where for example running `make crossgcc-arm`
ails as MPC cannot be built.
Building MPC 1.0.1 ... failed
As it worked for others, it turns out that I had a release archive for
MPC 1.0.1 cached from October 2014, which was generated incorrectly, so
that `./configure` and `Makefile` are missing.
$ LANG=C ls -l util/crossgcc/tarballs/mpc-1.0.1.tar.gz
-rw-r--r-- 1 joey joey 224232 Oct 19 2013 util/crossgcc/tarballs/mpc-1.0.1.tar.gz
$ md5sum util/crossgcc/tarballs/mpc-1.0.1.tar.gz
22a27bee89616dca4d654fc579a816e5 util/crossgcc/tarballs/mpc-1.0.1.tar.gz
$ md5sum mpc-1.0.1.tar.gz # downloaded today
b32a2e1a3daa392372fbd586d1ed3679 mpc-1.0.1.tar.gz
So upgrade to MPC 1.0.3 as the release archive as of today contains the
needed files.
$ md5sum util/crossgcc/tarballs/mpc-1.0.3.tar.gz
d6a1d5f8ddea3abd2cc3e98f58352d26 util/crossgcc/tarballs/mpc-1.0.3.tar.gz
Change-Id: Ibfd02a9b362b12361b210d512420b87caebb0fdf
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
TEST:Run `make crossgcc-arm` and observe `Building MPC 1.0.3 ... ok`.
Reviewed-on: http://review.coreboot.org/8521
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A leading double slash can result when $DESTDIR/$TARGETDIR is expanded
in the libelf portion of buildgcc. The leading double slash causes buildgcc to fail when run from Windows/Msys2. Replace $DESTDIR/$TARGETDIR
with $DESTDIR$TARGETDIR to avoid the problem.
Change-Id: Ide2bae41c07c1566f80104c3a2e2acab53de0d17
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/7788
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The libelf build system doesn't support the
DESTDIR variable. Work around by mangling prefix
when installing.
Change-Id: I3a56eb2bf919bcb9b586b945dce26a02dbaff931
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7613
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
gcc 4.9.2 fails on our tree right now. We should clean that
up and test before we make it the reference version.
Also, the AMD K8/Fam10 issue we had last year, for which
Vladimir provided an "untested" fix (which is in,
commit a6c29fe684), isn't
reproducible: I boot-tested an unpublished AMD K8 board
with coreboot built with gcc 4.8.3.
(Disclaimer: since the old issue depended on compiler
decisions on register allocation, any change to code
or compiler could mix up things in semi-random ways.)
Change-Id: I8f1460a8da2c9e2d581482b22a4824b10b8987fa
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7526
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Unlike OSX 10.8, OSX 10.9 doesn't provide GNU tar program, and built-in
tar program is bsdtar 2.8.3. bsdtar can build crossgcc toolchain.
Modify buildgcc to support tar in OSX 10.9 (uname = Darwin).
Change-Id: I093898f8f99e29918387f9b275a30af461a7e1be
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/5598
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
cleanup() uses BUILDDIRPREFIX, which is set after the
getopt loop.
Change-Id: I8a904781ee4fefc42681d31e94b64008cf03750a
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4544
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
If the unpacking was interrupt by Ctrl-C, probably part of
an archive is unpacked. If we run buildgcc again, the
incomplete folder would be and skipped.
We can create a file to tell the script the unpacking is done.
Change-Id: Id9eb74d119e22b62c70dca9b38a92c3dbdf0f64c
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/4512
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
gcc 4.8.x has issues with using ebp, which broke some builds,
so downgrade. The problem also manifested elsewhere, so it's
not necessarily our fault.
While at it, gcc complained about "armv7a" where it seems to
expect "armv7-a".
Change-Id: I6f0c35f49709cb41022475bb47116c12ab1c7ee3
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3930
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This simplifies debugging and also fixes an issue when build directories
are kept between buildgcc runs for different architectures.
Change-Id: I5badccd3368e3014680da3eedb607119fff8fa7f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3929
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
acpica-unix-20130626 doesn't use bin32 and bin64 to save the objects
any more.
Change-Id: I419ecc987e2adcd860a8ad1bf2f6b5c4dd40fd8a
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/3885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
While some of the case .. break statement actually weren't needed,
too are, since otherwise the option parsing loop hangs.
Exit conditions for that endless loop: "--" or no more arguments,
in line with GNU command line parsing rules.
Change-Id: I0dbc35e530fb8c93a0f7de05ac47f325555ad4a4
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/3418
Tested-by: build bot (Jenkins)
Reviewed-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Bash case statements are terminated with ';;'.
Unlike C, bash case statements will not continue to the next case. No 'break' is needed.
Change-Id: I62e7e91f3223ac4052728a1ca12a4681af0dc036
Signed-off-by: David Hubbard <david.c.hubbard+coreboot@gmail.com>
Reviewed-on: http://review.coreboot.org/3330
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
buildgcc has many wrong choices, and two right ones,
but you would never guess that. It's even more
frustrating when it spends lots of time building a
full tool chain and you find out it's not the one you
wanted and, still worse, you've forgotten what it does want
and, even worse, it won't f-ing tell you what the two
right choices are!.
Have it tell you when you've done something wrong, and have it
make reasonable decisions when you say things like
-p arm
instead of
-p armv7a-eabi
This change lowers my blood pressure 10 points.
Change-Id: I44a59d7cb7a6260894d8bcb692a693ed25681ff8
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/3292
Tested-by: build bot (Jenkins)
Update crossgcc to use gcc 4.7.3
The resulting coreboot.rom is not runtime tested (any volunteers?).
Drop the texinfo patch, rename the armv7a patch.
Some Linux distributions have moved on to gcc 4.8,
under certain circumstances this version can't (cross-)compile gcc 4.7.2
Bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56927
Change-Id: Id8ce5f86c34e1a0900d44dc6ae4e81cb9548ecc2
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3112
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The URL to acpica-unix-20121114 has changed, update the URL.
Change-Id: I1c8c228094f19455af3682f36f1990586fe3934c
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/3070
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
In case that the new toolchains don't work well, we can trace back
and reproduce the old tools by checking the xgcc folder. It is useful
when my team members need to get my old toolchains on their own host
machines.
Change-Id: I54e4bc6afcfbbf622165af6eae27bbb6efc2e8cc
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: zbao <fishbaozi@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2247
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Various of the build scripts used upstream can't cope with
multilib library paths (eg. lib64), so move things to a place
where they can find them, if such paths are used.
Change-Id: I0dd9bba9a9eadd92d8704157e868fb37c715ee91
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2013
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This puts our installed binaries first in the search path, which is what we
really want.
... and remove some dead code
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I91725af6b0fc486bd943d8e25cdce8d3e2503b3c
Reviewed-on: http://review.coreboot.org/1998
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The focus of the script is to create a supported cross toolchain,
and with GOLD and LTO being released features, we don't need this
anymore.
Change-Id: Ieb7752ce6e143d93414aba5887190f853cbd5a4b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1997
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
After patching them to be more flexible, an even better approach was found:
With this change libgcc isn't built at all on mingw32 platforms, so the
system headers aren't necessary anymore.
Now x86_64-pc-mingw32 builds, too.
Change-Id: Ic1406588669d87aee1bcf40ff67af77f2a6ac283
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1985
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Raymond Danks <ray.danks@se-eng.com>
With this change, i686-pc-mingw32 is acceptable, too.
Change-Id: I924f7ece84e77dc751e5e0318bac1ebc72d39d21
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1972
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Nico Huber