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>
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>
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>
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>
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>
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>
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>
Once again, the compiler we use on Mac OS X had trouble compiling GCC.
Switch to llvm-gcc because that one works with Xcode 4.5.2 and gcc 4.7.2.
Also drop the -W flags not known to Xcode from the iasl Makefile, and
drop the --remove-destination option from the copy, because that does not
exist on Darwin.
Change-Id: I9f978f65b5ae7edee2ecdcab337772e7a692bd9b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1967
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Update acpica to release 20121114 and
update patches/ to build with this version of acpica.
Correct the creation of crossgcc-build.log
Bump CROSSGCC_VERSION.
Change-Id: I269454ebc3c78b5852e4a67e55bb5642edad191d
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/1861
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This is no GNU tool, so testing for "GNU" in the version string
is bound to fail.
We now accept everything that returns success on "flex --version"
and then hope for the best.
I tested both cases
Change-Id: If325f613fde1648847b998b7e8e5782d0f22b484
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/1884
Tested-by: build bot (Jenkins)
Reviewed-by: Zheng Bao <zheng.bao@amd.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
flex is needed by acpica. This patch makes the build fail early
instead of after gcc has been compiled, if flex is not there.
Change-Id: Idfd71bdf704ab25de655f1a72c266c5220b15048
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/1860
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Don't let expat and/or python show the compile process on stdout.
Instead direct this output to crossgcc-build.log.
Fix the logfile path for python.
Change-Id: I431dabf6955d7eef3e54c96d0fb11b92d1cee96d
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/1667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
