aarch64-binutils is no longer built static by default, so aarch64-gcc
can now enable LTO.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25783
- Add --with-sysroot=/ to CONFIGURE_ARGS. base/binutils needs this so
that ld honors --sysroot in linker scripts. base/gcc6 needs this so
that the C++ include paths honor --sysroot.
- Remove a hack from GCC's configure to force C++98 mode when building
GCC with GCC. libc++ assumes C++11, so this hack was breaking the
build of base/gcc6 natively when the system compiler was GCC.
- Add toolchain makefiles installed to /usr/share/toolchains.
These are suitable to be used by CROSS_TOOLCHAIN when doing a native
arch build. These makefiles enable appropriate knobs so that the
in-tree components that are replaced by each package are not built
or installed. The freebsd-gcc toolchain makefile includes the
binutils toolchain makefile if it is present.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D22984
This is in preparation for adding a base/gcc9 port.
While here, update to GCC 6.5.0.
Share packing lists with the freebsd-gcc6 port as much as posible.
Split most of the freebsd-gcc6 pkg-plist into a pkg-plist.common that
lists arch-independent files under lib/. Change base/gcc6 to use the
arch-specific packing lists and pkg-list.common from freebsd-gcc6. In
addition, hook up packing lists for the remaining archs supported by
freebsd-gcc6 but not base/gcc6: aarch64 and sparc64.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D22900
- Explicitly set all the toolchain <foo>_FOR_TARGET variables.
GCC's default guess for CC, etc. happened to work with the
powerpc64-gcc port, but fails when the binaries have a suffix
like the '6' suffix in freebsd-gcc6. Setting these variables
explicitly keeps GCC's build from having to guess.
- Pull patches from freebsd6-gcc instead of powerpc64-gcc.
- Use per-arch plists.
- Simplify the post-install steps to keep the hard links the
normal install performs and avoid renaming binaries.
Keep links to 'cc' and 'c++'.
Reviewed by: bapt (earlier version)
Differential Revision: https://reviews.freebsd.org/D22594
While here, make the port autonomuous (not a slave port of devel/binutils
anymore)
The only dependency this port is keeping with devel/binutils is sharing the
patch directory to avoid duplication.
Use HOSTARCH to set CONFIGURE_TARGET instead of ARCH.
Reported by: Mark Millard
Approved by: bapt (maintainer)
Differential Revision: https://reviews.freebsd.org/D19484
- Don't require CROSS_TOOLCHAIN and CROSS_SYSROOT.
- Handle building for an amd64 target which needs x86_64 in
CONFIGURE_TARGET for similar reasons described in r475291.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D19129
- Don't require CROSS_TOOLCHAIN and CROSS_SYSROOT for base/binutils.
- Fix some places in devel/binutils to test the PREFIX instead of
CROSS_TOOLCHAIN to determine if base/binutils is being built.
- When base/binutils is built natively, the binaries are installed
with the target name prefix already.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D19128
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
Simplify some ports where DragonFlyBSD no longer needs to be special-cased.
Submitted by: rene
Reviewed by: bapt, jbeich
Differential Revision: https://reviews.freebsd.org/D17724
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
- Drop plist entries from devel/binutils that are now properly removed.
Previously the binaries for Windows tools like dlltool were removed
from the staging area but the manpages were still left in the package.
- Bump PORTREVISION.
This is a recommit of r476186 but with the update to the pkg-plist of
devel/binutils and PORTREVISION bump.
PR: 230278
Reviewed by: antoine
Differential Revision: https://reviews.freebsd.org/D16582
- Use BUREMOVE to strip binutils tools not installed by the base/binutils
package.
- Update BUREMOVE logic in devel/binutils to cope with the base package
which installs tools without a BUTARGET- prefix.
- Use MANPREFIX for BUREMOVE to handle the PREFIX=/usr case used by
base/binutils.
- Remove binutils headers and libraries explicitly from the staging area
for base/binutils.
- Add missing plist entries for binutils binaries installed under a
BUTARGET subdirectory.
Approved by: bapt (implicit for base/*)
Differential Revision: https://reviews.freebsd.org/D16464
- To support amd64, map amd64 to x86_64 when generating the --host argument
to configure in bsd.port.mk and when generating --target arguments in port
Makefiles.
- Add entries to the plists for i386 and amd64. amd64 generally includes both
amd64-specific entries as well as i386 entries.
- Don't include the builtin float.h for i386 and amd64.
Reviewed by: bapt
Approved by: portmgr (bapt)
Differential Revision: https://reviews.freebsd.org/D16250
For base/gcc, only enable .init_array and .fini_array for 12.0 and later
to match the policy used by clang and llvm. For the xtoolchain ports,
enable these unconditionally since the only OS version handy is the OS
version of the build host, not the target OS to be built. Unlike llvm,
the use of .init_array and .fini_array is set at compile-time for GCC
and can't be changed at runtime.
Bump PORTREVISION for base/gcc and the xtoolchain GCC ports.
Reviewed by: bapt (earlier version)
Differential Revision: https://reviews.freebsd.org/D16014
Create a single pkg-plist that uses arch-specific PLIST_SUBs to control
arch-specific linker scripts but is otherwise machine-independent.
- Only include objcopy for OS versions older than 11.0 (11.0 uses the
elftoolchain elfcopy as objcopy in the base system)
- Use %%BUTARGET%% throughout. This probably fixes the sparc64 pkg-plist
which was not updated when BUTARGET started including OSREL. This also
avoids hardcoding an OSREL of 12.0 for powerpc64.
- Enable MIPS ldscripts for all MIPS architectures which probably fixes
this port on mips64 and mipsn32.
- Enable PowerPC ldscripts for all PowerPC architectures which probably
fixes this port on powerpc.
Reviewed by: bapt, bdrewery
- When cross-building packages, set ARCH to the target arch instead of
the arch of the build host. This fixes bsd.ssp.mk on MIPS which was
trying to enable SSP on MIPS cross-built packages because the host
ARCH was amd64. A new HOST_ARCH variable is added to set the
--build triple for configure scripts, but I believe most other uses of
ARCH in ports are really about the target, not the build host so this
is the more correct general direction.
- Some updates to base/binutils and base/gcc to use ARCH as the target
architecture.
- Drop the extra arguments to GCC to set include and library paths and
only set --sysroot.
- Move the --sysroot flags into CC, CXX, CPP (which is now set to XCPP)
and LD instead of passing it in CFLAGS, etc. The base/gcc build uses
ends up using the CFLAGS when building native binaries for the build
host which fails when tripping over the --sysroot. I think this might
have accidentally worked before because the powerpc64 headers in
/usr/include/machine were "close enough" to the amd64 headers, but with
32-bit MIPS this failed hard.
- Add the GCC MIPS patch from devel/powerpc64-gcc to base/gcc to add
MIPS support to base/gcc.
- Add a MIPS plist for base/binutils.
- Set helper variables for the base/gcc plist to tag architecture-specific
headers (e.g. for intrinsincs) and use these to tag powerpc and MIPS
specific headers.
- Drop the include-fixed headers from base/gcc.
- Strip /usr/local/include from the default list of include paths for
base/gcc.
- Use libc++'s include path for C++ for base/gcc.
Reviewed by: bapt
Approved by: portmgr (bapt)
Differential Revision: https://reviews.freebsd.org/D15267
This is a follow up to r461057 and fixes base/binutils and base/gcc in my
testing.
PR: 224217
Submitted by: nwhitehorn (partially, I made additional changes)
Reviewed by: bapt
locale set by the user. Add LANG=C and LC_ALL=C at the beginning of
bsd.port.mk and export them so all commands are executed with the C locale.
LC_ALL=C overrides all other LC_* variables. LANG is used by setlocale(3)
as default value for LC_* variables, so normally it isn't used when LC_ALL
is set, but there's code out there that looks at LANG directly so it's safer
to set it as well. The only commands not captured by this are !=
assignments before any inclusion of bsd.port.*mk.
Introduce USE_LOCALE=<locale> that adds LANG=<locale> and LC_ALL=<locale> to
CONFIGURE_ENV and MAKE_ENV so upstream build systems can be executed with a
different locale (e.g. USE_LOCALE=en_US.UTF-8).
PR: 215882
Exp-run by: antoine
Approved by: portmgr (antoine)
This port is special, it is done only for being cross build and prepare a modern
compiler for base system build without a cross compiler
It contains the printf format extension needed for the kernel as only patch for
now.
It uses libc++ from base as a standard c++ library default on the libc++ headers
as c++ headers
Add a cross buildable binutils package.
The new category is not linked to the regular ports tree to avoid make install,
poudriere and others to catch it automagically
instead of ending with a very complex file removal in the stage, prefer to use
specific plist per arch.
For now only sparc64 tested and added. This version of binutils is stipped down
only the components that are not supported by elftoolchain
