summaryrefslogtreecommitdiffstats
path: root/Makefile.inc1
Commit message (Collapse)AuthorAgeFilesLines
* MFC r322951:ngie2017-09-301-2/+6
| | | | | | | | | | | | | Respect MK_TCSH with build-tools and native-xtools This helps reduce the WORLDTMP footprint slightly. Based on a patch I submitted 5 years ago to GNATS. PR: 174051 Relnotes: yes (anyone who cross-builds with MK_TCSH=yes will run into build failures if the host doesn't have tcsh(1)) Reminded by: Fabian Keil <fk@fabiankeil.de>
* MFC r321876:ian2017-09-111-4/+1
| | | | | | In xdev-links, when installing symlinks to the cross-compiler pieces that includes the OS version (armv6-freebsd12.0-cc, etc), use the OS version of the compiler/world source code, not the version of the build host machine.
* MFC r321684:dim2017-08-121-4/+2
| | | | | | | | | | | | | | | | | | | | | | Don't use libc++ when cross-building for gcc arches Since we imported clang 5.0.0, the version check in Makefile.inc1 which checks whether to use libc++ fires even when the compiler for the target architecture is gcc 4.2.1. This is because only X_COMPILER_VERSION is checked. Also check X_COMPILER_TYPE, so it will only use libc++ when an external gcc toolchain is used. Reviewed by: emaste, rpokala Differential Revision: https://reviews.freebsd.org/D11776 MFC r322170: Follow-up to r321684 (Don't use libc++ when cross-building for gcc arches), and handle two more cases where libc++ includes could be incorrectly enabled, in case the host compiler is clang 5.0.0, and the target (cross) compiler is gcc 4.2.1. Noted by: bdrewery
* MFC r320292:bdrewery2017-07-211-0/+1
| | | | NO_ROOT: Remove excessive // when DESTDIR/DISTDIR are empty.
* MFC r320806:bdrewery2017-07-211-1/+9
| | | | SYSTEM_COMPILER: Ensure there is not a stale compiler in WORLDTMP.
* MFC r319219: add a sanity check before installworld on the running systememaste2017-07-161-0/+16
| | | | | | | | | | | | | | | | FreeBSD does not guarantee kernel forward compatibility (that is, running a newer userland on an older kernel). The documented upgrade procedure specifies that installkernel should be performed, followed by a reboot and then installworld. As a sanity check when installing onto the running system (DESTDIR is / or unset), attempt to run "sh echo OK" using rescue from the objdir. If rescue fails (e.g., because the system has not been rebooted and the "old" kernel lacks a system call required by the to-be-installed world), abort the installation. This was added to avoid ino64 foot-shooting in HEAD, but is generally useful for any upgrade case adding new syscalls. Sponsored by: The FreeBSD Foundation
* MFC r306375,r307802:ngie2017-05-301-4/+6
| | | | | | | | | | | | | | | | | | r306375 (by emaste): Add a WITHOUT_DIALOG src.conf(5) knob It also turns off dependencies (bsdinstall, bsdconfig, dpv, tzsetup). r307802 (by bapt): Fix build of tzsetup when WITHOUT_DIALOG is set Hide dialog specific code behind HAVE_DIALOG. It allows to build a stripped down version (missing the dialog UI) but perfectly function tzsetup when world is built WITHOUT_DIALOG Reorganise a bit the code to limit the number of blocks under HAVE_DIALOG
* MFC r309412,r316109,r316132:ngie2017-05-281-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | r309412 (by imp): dd is currently a bootstrap tool. It really doesn't have any business being a bootstrap tool. However, for reproducible build output, FreeBSD added dd status=none because it was otherwise difficult to suppress the status information, but retain any errors that might happen. There's no real reason that dd has to be a build tool, other than we use status=none unconditional. Remove dd from a bootstrap tool entirely by only using status=none when available. This may also help efforts to build the system on non-FreeBSD hosts as well. r316109: Don't hardcode input files for stage 1/2 bootloaders; use .ALLSRC instead This is a better pattern to follow when creating the bootloaders and doing the relevant space checks to make sure that the sizes aren't exceeded (and thus, copy-pasting is a bit less error prone). r316132: Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/... This is being done to make it easier to change in the future--this action might be needed sooner rather than later because of gcc 6.3.0 bailing, stating that there is negative free space left (deficit) in the boot2 bootloader.
* Update stable/11 from 11.0-STABLE to 11.1-PRERELEASE, marking thegjb2017-05-191-1/+1
| | | | | | | | | | | official start of the code slush. Set the default mdoc(7) version to 11.1, and update the clang(1) TARGET_TRIPLE to reflect 11.1. While here, add missing FreeBSD major versions to mdoc(7). Approved by: re (implicit) Sponsored by: The FreeBSD Foundation
* MFC LLD changes and enable LLD as /usr/bin/ld on arm64 by defaultemaste2017-05-181-8/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFC r316629: do not require binutils port when using lld as ld r279908 added logic to Makefile.inc1 to automatically set CROSS_BINUTILS_PREFIX for architectures not supported by the in-tree binutils: arm64 when first introduced, and later riscv64 as well. LLVM's LLD linker is now included in the base system, and is enabled by default for arm64 and capable of linking world and kernel. Thus, avoid automatically setting CROSS_BINUTILS_PREFIX and requiring the binutils port if WITH_LLD_IS_LD is true. -- MFC r317608: revert r313473 (Disable LLD_IS_LD option combinations that fail) r316647 corrected the build of tblgen and libllvm as dependencies for LLD so undo the temporary seat-belt. We still want to extend the build infrastructure to automatically detect the case where the host LLD can be used instead of building a bootstrap LLD, and likely extend libllvmminimal to meet LLD's needs for cases where the build includes LLD but not Clang. -- MFC r316684: Make WITHOUT_TOOLCHAIN imply WITHOUT_LLD. LLD is a toolchain component. -- MFC r316647: Introduce LLD_BOOTSTRAP to control lld as bootstrap linker Add WITH_LLD_BOOTSTRAP and WITHOUT_LLD_BOOTSTRAP knobs, similar to the Clang bootstrap knobs. Reviewed by: andrew Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D10793
* MFC r316794:bdrewery2017-04-281-6/+35
| | | | Cache compiler metadata and reuse it at installworld time.
* MFC r316780:bdrewery2017-04-281-1/+4
| | | | Pass COMPILER_FEATURES down to submakes for installworld.
* MFC r316586:bdrewery2017-04-281-2/+2
| | | | META_MODE: Fix build-tools still sometimes rebuilding during target build.
* MFC r317100:gjb2017-04-211-2/+2
| | | | | | | | Use relative symlink for 'latest' to allow repo to work after being moved. PR: 217197 Sponsored by: The FreeBSD Foundation
* MFC r310181 (matthew) (originally r309314):gjb2017-04-211-14/+15
| | | | | | | Allow a user-overridable setting 'PKG_CMD' to control the command used to create a repo during 'make packages'. Sponsored by: The FreeBSD Foundation
* MFC r315691:bdrewery2017-04-131-5/+5
| | | | Rename _cc to _gcc to be more clear.
* Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release:dim2017-04-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MFC r309142 (by emaste): Add WITH_LLD_AS_LD build knob If set it installs LLD as /usr/bin/ld. LLD (as of version 3.9) is not capable of linking the world and kernel, but can self-host and link many substantial applications. GNU ld continues to be used for the world and kernel build, regardless of how this knob is set. It is on by default for arm64, and off for all other CPU architectures. Sponsored by: The FreeBSD Foundation MFC r310840: Reapply 310775, now it also builds correctly if lldb is disabled: Move llvm-objdump from CLANG_EXTRAS to installed by default We currently install three tools from binutils 2.17.50: as, ld, and objdump. Work is underway to migrate to a permissively-licensed tool-chain, with one goal being the retirement of binutils 2.17.50. LLVM's llvm-objdump is intended to be compatible with GNU objdump although it is currently missing some options and may have formatting differences. Enable it by default for testing and further investigation. It may later be changed to install as /usr/bin/objdump, it becomes a fully viable replacement. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8879 MFC r312855 (by emaste): Rename LLD_AS_LD to LLD_IS_LD, for consistency with CLANG_IS_CC Reported by: Dan McGregor <dan.mcgregor usask.ca> MFC r313559 | glebius | 2017-02-10 18:34:48 +0100 (Fri, 10 Feb 2017) | 5 lines Don't check struct rtentry on FreeBSD, it is an internal kernel structure. On other systems it may be API structure for SIOCADDRT/SIOCDELRT. Reviewed by: emaste, dim MFC r314152 (by jkim): Remove an assembler flag, which is redundant since r309124. The upstream took care of it by introducing a macro NO_EXEC_STACK_DIRECTIVE. http://llvm.org/viewvc/llvm-project?rev=273500&view=rev Reviewed by: dim MFC r314564: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 (branches/release_40 296509). The release will follow soon. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Also note that as of 4.0.0, lld should be able to link the base system on amd64 and aarch64. See the WITH_LLD_IS_LLD setting in src.conf(5). Though please be aware that this is work in progress. Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/4.0.0/tools/lld/docs/ReleaseNotes.html> Thanks to Ed Maste, Jan Beich, Antoine Brodin and Eric Fiselier for their help. Relnotes: yes Exp-run: antoine PR: 215969, 216008 MFC r314708: For now, revert r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 This commit is the cause of excessive compile times on skein_block.c (and possibly other files) during kernel builds on amd64. We never saw the problematic behavior described in this upstream commit, so for now it is better to revert it. An upstream bug has been filed here: https://bugs.llvm.org/show_bug.cgi?id=32142 Reported by: mjg MFC r314795: Reapply r287232 from upstream llvm trunk (by Daniil Fukalov): [SCEV] limit recursion depth of CompareSCEVComplexity Summary: CompareSCEVComplexity goes too deep (50+ on a quite a big unrolled loop) and runs almost infinite time. Added cache of "equal" SCEV pairs to earlier cutoff of further estimation. Recursion depth limit was also introduced as a parameter. Reviewers: sanjoy Subscribers: mzolotukhin, tstellarAMD, llvm-commits Differential Revision: https://reviews.llvm.org/D26389 Pull in r296992 from upstream llvm trunk (by Sanjoy Das): [SCEV] Decrease the recursion threshold for CompareValueComplexity Fixes PR32142. r287232 accidentally increased the recursion threshold for CompareValueComplexity from 2 to 32. This change reverses that change by introducing a separate flag for CompareValueComplexity's threshold. The latter revision fixes the excessive compile times for skein_block.c. MFC r314907 | mmel | 2017-03-08 12:40:27 +0100 (Wed, 08 Mar 2017) | 7 lines Unbreak ARMv6 world. The new compiler_rt library imported with clang 4.0.0 have several fatal issues (non-functional __udivsi3 for example) with ARM specific instrict functions. As temporary workaround, until upstream solve these problems, disable all thumb[1][2] related feature. MFC r315016: Update clang, llvm, lld, lldb, compiler-rt and libc++ to 4.0.0 release. We were already very close to the last release candidate, so this is a pretty minor update. Relnotes: yes MFC r316005: Revert r314907, and pull in r298713 from upstream compiler-rt trunk (by Weiming Zhao): builtins: Select correct code fragments when compiling for Thumb1/Thum2/ARM ISA. Summary: Value of __ARM_ARCH_ISA_THUMB isn't based on the actual compilation mode (-mthumb, -marm), it reflect's capability of given CPU. Due to this: - use __tbumb__ and __thumb2__ insteand of __ARM_ARCH_ISA_THUMB - use '.thumb' directive consistently in all affected files - decorate all thumb functions using DEFINE_COMPILERRT_THUMB_FUNCTION() --------- Note: This patch doesn't fix broken Thumb1 variant of __udivsi3 ! Reviewers: weimingz, rengolin, compnerd Subscribers: aemerson, dim Differential Revision: https://reviews.llvm.org/D30938 Discussed with: mmel
* RFC: 312593, 313958bapt2017-04-021-4/+3
| | | | Update mandoc to 1.14
* MFC r314709,r314790,r314794:bdrewery2017-03-221-2/+6
| | | | | | | | | | | r314709: Fix bootstrapping mtree after r313404 for older systems. r314790: Added comments for why nmtree/libmd are bootstrapped. r314794: Fix bootstrapping libmd on older systems after r314709. PR: 217673
* MFC r313907:bdrewery2017-03-031-4/+19
| | | | xdev: Fix after libc++ update in r300873.
* MFC r313905:bdrewery2017-03-031-1/+2
| | | | xdev: Build yacc which is needed for recent libpcap updates.
* MFC r313904:bdrewery2017-03-031-0/+4
| | | | META_MODE+xdev: Don't rebuild build-tools during normal build.
* MFC r313163:bdrewery2017-03-031-0/+1
| | | | native-xtools: Add missing readelf.
* MFC r313184:bdrewery2017-03-031-2/+0
| | | | Remove LOCAL_LIB_DIRS warning added in r275839.
* MFC r313924,r313925:ngie2017-02-251-3/+3
| | | | | | | | | | | | | | | | r313924: Quote path to doxygen/kyua in test(1) -x check This is a basic stopgap against ${LOCALBASE} containing spaces in it r313925: Include ${LOCALBASE}/bin in $PATH when running "make checkworld" Some of the tests in devel/atf // devel/kyua rely on the tools being in $PATH, which means that the tests fail when run via "make checkworld" because $PATH is restricted to exclude directory elements like "${LOCALBASE}/bin".
* MFC r313182:ngie2017-02-071-2/+2
| | | | Fix typo in variable name (_REDUNDENT_LIB_DIRS -> _REDUNDANT_LIB_DIRS)
* MFC r311140:ngie2017-01-161-1/+1
| | | | | | | | | | | | Only bake krb5_config.h support in to ssh(3), etc if both MK_GSSAPI and MK_KERBEROS_SUPPORT != no This fixes the odd case where someone specified MK_GSSAPI=no and MK_KERBEROS_SUPPORT=yes (which admittedly, probably doesn't make sense, but the build system doesn't prevent this case today, and it didn't when I filed the bug back in 2011 either). PR: 159745
* MFC 307538,307948,308602,308603,311151: Move kdump's mksubr into libsysdecode.jhb2017-01-121-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 307538: Move mksubr from kdump into libsysdecode. Restructure this script so that it generates a header of tables instead of a source file. The tables are included in a flags.c source file which provides functions to decode various system call arguments. For functions that decode an enumeration, the function returns a pointer to a string for known values and NULL for unknown values. For functions that do more complex decoding (typically of a bitmask), the function accepts a pointer to a FILE object (open_memstream() can be used as a string builder) to which decoded values are written. If the function operates on a bitmask, the function returns true if any bits were decoded or false if the entire value was valid. Additionally, the third argument accepts a pointer to a value to which any undecoded bits are stored. This pointer can be NULL if the caller doesn't care about remaining bits. Convert kdump over to using decoder functions from libsysdecode instead of mksubr. truss also uses decoders from libsysdecode instead of private lookup tables, though lookup tables for objects not decoded by kdump remain in truss for now. Eventually most of these tables should move into libsysdecode as the automated table generation approach from mksubr is less stale than the static tables in truss. Some changes have been made to truss and kdump output: - The flags passed to open() are now properly decoded in that one of O_RDONLY, O_RDWR, O_WRONLY, or O_EXEC is always included in a decoded mask. - Optional arguments to open(), openat(), and fcntl() are only printed in kdump if they exist (e.g. the mode is only printed for open() if O_CREAT is set in the flags). - Print argument to F_GETLK/SETLK/SETLKW in kdump as a pointer, not int. - Include all procctl() commands. - Correctly decode pipe2() flags in truss by not assuming full open()-like flags with O_RDONLY, etc. - Decode file flags passed to *chflags() as file flags (UF_* and SF_*) rather than as a file mode. - Fix decoding of quotactl() commands by splitting out the two command components instead of assuming the raw command value matches the primary command component. In addition, truss and kdump now build without triggering any warnings. All of the sysdecode manpages now include the required headers in the synopsis. 307948: Use binary and (&) instead of logical to extract the mask of a capability. 308602: Generate and use a proper .depend file for tables.h. 308603: Move libsysdecode-specific hack out of buildworld. This should fix the lib32 build since it was not removing the generated ioctl.c. This file is generated by a find(1) call, so cannot use normal dependency tracking methods. 311151: Update libsysdecode for getfsstat() 'flags' argument changing to 'mode'. As a followup to r310638, update libsysdecode (and kdump) to decode the 'mode' argument to getfsstat(). sysdecode_getfsstat_flags() has been renamed to sysdecode_getfsstat_mode() and now treats the argument as an enumerated value rather than a mask of flags.
* MFC r311131:dim2017-01-061-0/+1
| | | | | | | | | | | | | | | | | | | | Make native-xtools build correctly after clang/llvm 3.9.0 import During the clang/llvm 3.9.0 import, the build structure for it was completely revamped. This broke the native-xtools target. It first attempts to build libllvmminimal, then the llvm-tblgen and clang-tblgen executables, but these fail to link because they are linked to the 'full' libllvm by default, as they normally are during the 'world' stage. To make these link against libllvmminimal instead, define TOOLS_PREFIX, similarly as during the bootstrap-tools phase. The value itself is empty, as we don't really want to use a prefix. Reviewed by: imp PR: 215684 Differential Revision: https://reviews.freebsd.org/D9026
* Revert MFC of r308603.bdrewery2017-01-031-0/+3
| | | | This depends on unmerged r307538 still.
* MFC r308603:bdrewery2017-01-031-3/+0
| | | | Move libsysdecode-specific hack out of buildworld.
* MFC r305256:bdrewery2017-01-031-1/+3
| | | | Bump __FreeBSD_version for crunchgen META_MODE fix in r311185.
* MFC r309124:dim2016-12-261-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.9.0 release, and add lld 3.9.0. Also completely revamp the build system for clang, llvm, lldb and their related tools. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Release notes for llvm, clang and lld are available here: <http://llvm.org/releases/3.9.0/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/clang/docs/ReleaseNotes.html> <http://llvm.org/releases/3.9.0/tools/lld/docs/ReleaseNotes.html> Thanks to Ed Maste, Bryan Drewery, Andrew Turner, Antoine Brodin and Jan Beich for their help. Relnotes: yes MFC r309147: Pull in r282174 from upstream llvm trunk (by Krzysztof Parzyszek): [PPC] Set SP after loading data from stack frame, if no red zone is present Follow-up to r280705: Make sure that the SP is only restored after all data is loaded from the stack frame, if there is no red zone. This completes the fix for https://llvm.org/bugs/show_bug.cgi?id=26519. Differential Revision: https://reviews.llvm.org/D24466 Reported by: Mark Millard PR: 214433 MFC r309149: Pull in r283060 from upstream llvm trunk (by Hal Finkel): [PowerPC] Refactor soft-float support, and enable PPC64 soft float This change enables soft-float for PowerPC64, and also makes soft-float disable all vector instruction sets for both 32-bit and 64-bit modes. This latter part is necessary because the PPC backend canonicalizes many Altivec vector types to floating-point types, and so soft-float breaks scalarization support for many operations. Both for embedded targets and for operating-system kernels desiring soft-float support, it seems reasonable that disabling hardware floating-point also disables vector instructions (embedded targets without hardware floating point support are unlikely to have Altivec, etc. and operating system kernels desiring not to use floating-point registers to lower syscall cost are unlikely to want to use vector registers either). If someone needs this to work, we'll need to change the fact that we promote many Altivec operations to act on v4f32. To make it possible to disable Altivec when soft-float is enabled, hardware floating-point support needs to be expressed as a positive feature, like the others, and not a negative feature, because target features cannot have dependencies on the disabling of some other feature. So +soft-float has now become -hard-float. Fixes PR26970. Pull in r283061 from upstream clang trunk (by Hal Finkel): [PowerPC] Enable soft-float for PPC64, and +soft-float -> -hard-float Enable soft-float support on PPC64, as the backend now supports it. Also, the backend now uses -hard-float instead of +soft-float, so set the target features accordingly. Fixes PR26970. Reported by: Mark Millard PR: 214433 MFC r309212: Add a few missed clang 3.9.0 files to OptionalObsoleteFiles. MFC r309262: Fix packaging for clang, lldb and lld 3.9.0 During the upgrade of clang/llvm etc to 3.9.0 in r309124, the PACKAGE directive in the usr.bin/clang/*.mk files got dropped accidentally. Restore it, with a few minor changes and additions: * Correct license in clang.ucl to NCSA * Add PACKAGE=clang for clang and most of the "ll" tools * Put lldb in its own package * Put lld in its own package Reviewed by: gjb, jmallett Differential Revision: https://reviews.freebsd.org/D8666 MFC r309656: During the bootstrap phase, when building the minimal llvm library on PowerPC, add lib/Support/Atomic.cpp. This is needed because upstream llvm revision r271821 disabled the use of std::call_once, which causes some fallback functions from Atomic.cpp to be used instead. Reported by: Mark Millard PR: 214902 MFC r309835: Tentatively apply https://reviews.llvm.org/D18730 to work around gcc PR 70528 (bogus error: constructor required before non-static data member). This should fix buildworld with the external gcc package. Reported by: https://jenkins.freebsd.org/job/FreeBSD_HEAD_amd64_gcc/ MFC r310194: Upgrade our copies of clang, llvm, lld, lldb, compiler-rt and libc++ to 3.9.1 release. Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11 support to build; see UPDATING for more information. Release notes for llvm, clang and lld will be available here: <http://releases.llvm.org/3.9.1/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/clang/docs/ReleaseNotes.html> <http://releases.llvm.org/3.9.1/tools/lld/docs/ReleaseNotes.html> Relnotes: yes
* MFC r309332:dim2016-12-061-0/+10
| | | | | | | | | | | Cleanup old debug dirs in delete-old-dirs target Any .debug or .symbols files under /usr/lib/debug which correspond to OLD_FILES entries in ObsoleteFiles.inc are also automatically cleaned up by the delete-old target. Make this also apply to any OLD_DIRS entries. Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D8683
* MFC: 306864,307648bapt2016-10-221-1/+1
| | | | Groff is needed only if MK_GROFF and MK_SHAREDOCS are both true.
* MFC r304217:bdrewery2016-08-191-10/+0
| | | | Trim unneeded bootstrap after r301470 made 9.1 the minimum supported release.
* MFC r304006:bdrewery2016-08-191-3/+3
| | | | Avoid showing the bootstrap make command for check-old, etc.
* MFC 303935lwhsu2016-08-171-1/+1
| | | | | | | | Only remove empty directories before packaging. This preserves files are intentionally empty, most of them are in tests.txz Reviewed by: bdrewery
* MFC r303274:bdrewery2016-07-271-7/+5
| | | | | | Don't disable binutils/elftoolchain bootstrapping with external compiler. Approved by: re (kib)
* MFC r303272,r303273:bdrewery2016-07-271-30/+48
| | | | | | | | | r303272: SYSTEM_COMPILER: Rework the logic to allow a 'make test-system-compiler'. r303273: Fix empty WANT_COMPILER_TYPE when neither compiler is bootstrapped. Approved by: re (kib)
* MFC r303034: Include makewhatis in ITOOLS when MK_MAN_UTILS is trueemaste2016-07-261-1/+1
| | | | | | | | | | | Previously it was conditional on MK_MAN. It's possible to build FreeBSD with man pages but without man page tools. MK_MAN_UTILS is the conditional used in share/man/Makefile for determining whether makewhatis is executed at install time, so it is the proper one for ITOOLS as well. PR: 210142 Approved by: re (gjb)
* WITH_SYSTEM_COMPILER: Don't enable for xdev or native-xtools.bdrewery2016-07-071-1/+1
| | | | | | | | | Otherwise they get no compiler. Reported by: swills Tested by: swills Approved by: re (gjb) Sponsored by: EMC / Isilon Storage Division
* WITH_SYSTEM_COMPILER: Avoid using GCC4.8+ logic on native GCC4.2 platforms.bdrewery2016-06-291-0/+2
| | | | | | | | | | | As the XXX notes, these should really be checking MK_GNUCXX since there is already a version check in share/mk/src.opts.mk to disable it. Fixing that here is more complex though. This could also be using X_COMPILER_FEATURES but uses X_COMPILER_VERSION to keep in sync with the src.opts.mk logic. Tested by: andreast Sponsored by: EMC / Isilon Storage Division Approved by: re (gjb)
* Fix native powerpc64 build of lib32 with in-tree GCC.bdrewery2016-06-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | - This was broken by r300350 and r300885. - Add some comments around the external GCC logic since it is spread out and in need of some cleanup. - The problem was that X_COMPILER_TYPE is always defined from CC->XCC's default, so if /usr/bin/cc is GCC (as it is on native powerpc64) then X_COMPILER_TYPE was getting GCC and triggering the external logic in Makefile.libcompat. It was intended to always provide -isystem with GCC since --sysroot is used into the lib32 sysroot which won't modify the header path without the -isystem. The use of the libc++/std=c++11 override was only intended to be used for external compilers though (more accurately GCC 4.8+ but that's a separate assumption to cleanup). Apply the same logic from Makefile.inc1 to Makefile.libcompat to only add the libc++ override when needed for external compilers. Pointyhat to: bdrewery Tested with: native ppc64 (swills), universe, ppc64 xtoolchain, amd64 xtoolchain, sparc64 cross-build of ppc64 (host GCC 4.2) Reported by: andreast, swills Approved by: re (gjb) Sponsored by: EMC / Isilon Storage Division
* build: Add legacy support for futimens() and utimensat().jilles2016-06-091-0/+2
| | | | | | | | | | | | | | | In order to allow using utimensat() in install(1), add futimens() and utimensat() to -legacy. The files futimens.c and utimensat.c are modified copies of the files under lib/libc/sys/ since the libc versions use symbols that do not exist in the libc on the build system (sys_futimens and sys_utimensat) . I expect the next non-sweeping change to both sets of files to be to delete them, anyway. This will allow reverting r299942 (which is a revert of r299850) enabling nanosecond timestamps in install(1). Reviewed by: bdrewery
* legacy: Avoid building/installing headers twice.bdrewery2016-06-051-2/+3
| | | | Sponsored by: EMC / Isilon Storage Division
* Add a MINIMUM_SUPPORTED_OSREL and bump it to 900044.bdrewery2016-06-051-2/+5
| | | | | | | This is actually a revision in the stable/9 branch released as 9.1. The localedef build requires xlocale from this period. Sponsored by: EMC / Isilon Storage Division
* Fix incorrect logic in r301394.bdrewery2016-06-041-1/+1
| | | | Reported by: Mark Millard
* Follow-up r301287: Pass external compiler metadata when used.bdrewery2016-06-041-0/+6
| | | | | | | This fixes WITH_SYSTEM_COMPILER, WITHOUT_CROSS_COMPILER, external compiler, to pass the external compiler metadata rather than the ${CC} metadata. On a build host that has clang as CC it was passing the clang metadata rather than GCC metadata during the build.
* WITHOUT_CROSS_COMPILER: Fix installworld.bdrewery2016-06-031-3/+9
| | | | | | | | | | | | | | Since no WORLDTMP/usr/bin/cc is created, cc cannot be found during installworld time since /usr/bin is not in the PATH. Pass along the known compiler metadata to allow installworld to work. The same fix was used for WITH_SYSTEM_COMPILER. A better route would be to store a cookie in buildworld containing this compiler metadata and then using that at install time, rather than rerunning cc. Reported by: Mark Millard Sponsored by: EMC / Isilon Storage Division
OpenPOWER on IntegriCloud