summaryrefslogtreecommitdiff
path: root/src/arch/x86/memmove.c
diff options
context:
space:
mode:
authorPatrick Georgi <pgeorgi@chromium.org>2018-06-26 21:00:58 +0200
committerPatrick Georgi <pgeorgi@google.com>2018-06-26 20:58:01 +0000
commit095db339f7463b09b52968fa3747aef329c7b83e (patch)
tree76ee2156fa2c681a4ef01fa498156817d4044118 /src/arch/x86/memmove.c
parentd1d85e8849b3b696d4148f1dd93dd93291095d52 (diff)
util/crossgcc: Allow building a new gcc against new binutils with -D
With -D, the newly built toolchain isn't installed into $prefix/... but into $DESTDIR/$prefix/... while being built for $prefix alone. This is useful for distributions, but it breaks down when the build host already has the toolchain installed in $prefix without proper build isolation (cf. gentoo): In such cases libgcc etc are built using the new compiler (as gcc's build system is smart enough to state the path explicitly), but that compiler then uses its regular algorithm to determine the path to as, ld, ... That makes it use the tools from $prefix, which might differ in formats (assembly, certain object file flags, ...): nds32le-elf in particular has rather unstable formats still, and so new compilers can't work with old binutils. The approach to deal with this is to take an unused path that's specified by gcc's build system ($out/gcc/$arch/$version) and symlink it to the new toolchain - these explicitly given directories take precedence over the default search path, and so the new binutils are used. Change-Id: Ia9a262e73f56cd486a2ae07422b598c205a03aed Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/27241 Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Diffstat (limited to 'src/arch/x86/memmove.c')
0 files changed, 0 insertions, 0 deletions