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>
Martin Roth