aboutsummaryrefslogtreecommitdiff
path: root/base
diff options
context:
space:
mode:
authorJohn Baldwin <jhb@FreeBSD.org>2019-01-25 19:04:49 +0000
committerJohn Baldwin <jhb@FreeBSD.org>2019-01-25 19:04:49 +0000
commit86c96ca1f29f8ffe79e65377c144d16bc8f47550 (patch)
treed74b3a453013973b658cdeb187070b508d34f1d7 /base
parent8b6f368a9a1a332be70eccefb8a6f20398638e09 (diff)
downloadports-86c96ca1f29f8ffe79e65377c144d16bc8f47550.tar.gz
ports-86c96ca1f29f8ffe79e65377c144d16bc8f47550.zip
Override the library search directories for external GCC toolchains.
The default library search directories when building a native GCC end up falling back to /usr/local/lib (for devel/*-gcc) and /usr/lib (for base/gcc) even when --sysroot is used. For devel/*-gcc, I previously forced CROSS_DIRECTORY_STRUCTURE on in r466699 to workaround this. However, this solution could not be used for base/gcc. Instead, patch the sources to remove several of the library search directories and override STARTFILE_PREFIX_SPEC to only look in /usr/lib. GCC still adds tuple-specific subdirs to /usr/lib, but this is ok. Bump PORTREVISION for both the external GCC toolchains and base/gcc. Reviewed by: kan Differential Revision: https://reviews.freebsd.org/D18677
Notes
Notes: svn path=/head/; revision=491173
Diffstat (limited to 'base')
-rw-r--r--base/gcc/Makefile3
1 files changed, 2 insertions, 1 deletions
diff --git a/base/gcc/Makefile b/base/gcc/Makefile
index 13b2fb0f2dde..e386afeb5f1b 100644
--- a/base/gcc/Makefile
+++ b/base/gcc/Makefile
@@ -2,7 +2,7 @@
PORTNAME= gcc
PORTVERSION= 6.4.0
-PORTREVISION= 1
+PORTREVISION= 2
CATEGORIES= base
MASTER_SITES= GCC/releases/gcc-${DISTVERSION} \
http://www.mpfr.org/mpfr-3.1.6/:mpfr \
@@ -44,6 +44,7 @@ PLIST_SUB= TARGETARCH=${TARGETARCH} \
GCC_VERSION=${PORTVERSION}
EXTRA_PATCHES+= ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-format-extensions
+EXTRA_PATCHES+= ${.CURDIR}/../../devel/powerpc64-gcc/files/freebsd-libdir
EXTRA_PATCHES+= ${.CURDIR}/../../devel/powerpc64-gcc/files/patch-gcc-freebsd-mips
GNU_CONFIGURE= yes