Without this change the buildworld/buildkernel epilogue looks like this:
>>> World built in 249 seconds, sysctl: cannot stat /proc/sys/hw/ncpu: No such file or directory
ncpu: , make -j72.
Reviewed By: emaste, bdrewery
Differential Revision: https://reviews.freebsd.org/D26056
This ensure that running make install inside buildenv correctly includes
the METALOG flags when building with -DNO_ROOT.
Reviewed By: brooks
Differential Revision: https://reviews.freebsd.org/D26038
upstream so Version.inc now only defines LLD_VERSION_STRING.
This breaks the WANT_LINKER_VERSION magic and might lead to us building
more than needed (e.g., for croos-tools).
Change the awk script to parse LLD_VERSION_STRING instead of LLD_VERSION,
which not only unbreaks the current situation but should also be backwards
compatible as dim points out.
PR: 248818
Reviewed by: emaste, dim (seems right and the way to go)
MFC after: 4 weeks
X-MFC before: 364284
Some of the scripts used for libdtrace invoke nawk instead of awk
(for example cddl/contrib/opensolaris/lib/libdtrace/common/mknames.sh).
When bootstrapping all tools, we get the nawk -> awk link while building
usr.bin/awk, but when linking/copying the dependencies from the host we
were only adding awk but not nawk.
This was silently generating invalid files when building libdtrace with
BUILD_WITH_STRICT_TMPPATH=1 since those scripts invoke nawk instead of
awk. In addition to adding the missing link this commit also adds
set -e to those scripts to catch errors like this in the future.
Reviewed By: markj, emaste
Differential Revision: https://reviews.freebsd.org/D26025
Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
This allows using LLVM objcopy to strip binaries instead of the in-tree
elftoolchain objcopy. We make use of this in CheriBSD since passing
binaries generated by our toolchain to elftoolchain strip sometimes results
in assertion failures.
This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516
by specifying STRIPBIN=/path/to/llvm-strip
Obtained from: CheriBSD
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D25988
make copies instead.
There's too many times that we can't run the new binaries with old
libraries. Making the links when things are known to be 'safe' is a
nice optimization, but a copy of all the binaries is only 30MB, so
saving the copies at the cost of increased support when new symbols
are added and used as part of the bootstrap seems to be unwise.
There may be additional optimizations possible here, especially for
!FreeBSD hosts. However, that's beyond the scope of the problem I'm
trying to fix with make failing mid-way through an installworld across
change r363679. This optimization there caused us to run a new binary
with an old library once a new make was installed due to the symbolic
link. One could just copy make, but then other binaries fail as well,
so rather than play whack-a-mole, I opted to take us back to the old
way. Before r340157 or so we did copies (thogh of a lot fewer
artifacts), and we didn't have issues like this.
Reviewed by: arichards@
Differential Revision: https://reviews.freebsd.org/D25967
The output dir is set to ${REPODIR}/${PKG_ABI}/${PKG_VERSION} now.
Add the possibility to specify the last componant and set it by default
to ${PKG_VERSION} as before.
This is useful for tests and also for building packages with the same
PKG_VERSION provided to check differences.
libarchive uses the SOURCE_DATE_EPOCH env variable to set the date of file
in an archive, this is useful for reproducibility.
Add a variable name PKG_TIMESTAMP that take a epoch time and set SOURCE_DATE_EPOCH
to this. By default it is the current time so no changes here.
In lib/Makefile, we document the dependency with SUBDIR_DEPEND
For buildworld orchestration, just prebuild libregex if GOOGLETEST is
enabled. googletest will get built in a later pass.
clang-format is enabled conditional on either WITH_CLANG_EXTRAS or
WITH_CLANG_FORMAT. Some sources in libclang are build conditional on
either rule, and obviously the clang-format binary itself depends on the
rule.
clang-format could still use a manual page.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D25427
As of r362452, liblzma depends on libmd but the buildworld build order
hadn't been amended to document the new dependency.
Reported by: jenkins via freqlabs
X-MFC-With: r362452
libucl comes with a Lua library binding. Build it into flua.
This lets us parse/generate config files in the various formats supported by
libucl with flua. For example, the following script will detect the format of
an object written to stdin as one of UCL config, JSON, or YAML and write it to
stdout as pretty-printed JSON:
local ucl = require('ucl')
local parser = ucl.parser()
parser:parse_string(io.read('*a'))
local obj = parser:get_object()
print(ucl.to_format(obj, 'json'))
Reviewed by: kevans, pstef
Approved by: mmacy (mentor)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D25009
As of r361857 all BINUTILS options are disabled by default - ports
have been changed to depend on binutils if they require GNU as, and
all base system assembly files have been switched to use Clang's
integrated assembler.
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
-development is long and awkward, and is also inconsistent with prior art
from the Linux world, which uses -dev (Debian) or -devel (Red Hat). Follow
the Debian convention, and similarly for debug info packages.
Also remove redundant pkgbase development tag from includes. We already tag
include files with package=runtime,dev; there is no need to separately tag
them as dev.
Discussed with: bapt
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24139
This was solving the correct-ish problem in the wrong place. Noted by
brooks; while he didn't request a prompt revert, doing so now will
facilitate proper testing for the revised version of this.
if foo; then blah else blah; fi has a drastically different meaning than
if foo; then blah; else blah; fi. Fix it.
Reported by: 0mp
X-MFC-With: r360833
This can be run as root or normal user with no problem; if they hadn't
twisted the WITHOUT_CAROOT knob, we'll attempt to use the host certctl to
rehash the DESTDIR. This would allow one to build systems WITHOUT_OPENSSL +
WITH_CAROOT with a populated /etc/ssl that they can then use with an
appropriate *ssl from somewhere else.
Cross-builds are fine because this will always use the host certctl, or just
nag if it's missing and it wasn't a WITHOUT_CAROOT build.
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D24641
The latter needs the former, but with a multi-job build on a fast
machine, the race is sometimes lost. This leads to "ld: error: unable to
find library -lsbuf", when linking libgeom.so.
Submitted by: kevans
MFC after: 3 days
r359461 introduced this nifty script to centralize these things, so add
shm_open.c there to remove a total of one (1) bad example from
Makefile.inc1.
Looked over by: emaste
instead of sprinkling them out over many disjoint files. This is a follow-up
to achieve the same goal in an incomplete rev.348521.
Approved by: imp
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D20520
By using -nobuiltininc and adding the clang builtin headers resource dir
to the end of the compiler header search path, we can still find headers
such as immintrin.h but find the FreeBSD version of stddef.h/stdarg.h/..
first.
This is a workaround until we are able to settle on and complete a plan
to harmonize guard macros with LLVM. We've mostly worked out this on
FreeBSD systems by removing select headers from the installed set of
devel/llvm*, but that isn't a good solution for cross build.
Submitted by: arichardson
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D17002
It's rather awkward to debug issues with the dependency cleanup hacks
when implemented via make. Add a cleanup shell script and move the
libomp hack there as an initial example.
Reviewed by: brooks
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D24228
After the base kyua import the testsuite can utilize the in-base kyua
just fine.
Submitted by: Dries Michiels
Differential Revision: https://reviews.freebsd.org/D24230
We need to build kyua libraries for kyua. Because we set MK_TESTS=no,
we can't not set MK_TESTS_SUPPORT=${MK_TESTS_SUPPORT} because the latter
defaults MK_TESTS_SUPPORT to no.
This fixes WITHOUT_TESTS + WITH_TESTS_SUPPORT builds.
Reported by: Ruslan Garipov
Reviewed by: emaste
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24206
Those libs aren't needed anymore so stop building them for the bootstrap tools
or the compat libs.
Reviewed by: bapt, emaste
X-Differential Revision: D24171
For the final step of the native-xtools target, "everything" is built
with TARGET and TARGET_ARCH set to the architecture we wish to
cross-build for. However, CROSSENV overwrites the values of MACHINE and
MACHINE_ARCH, setting them to be identical to TARGET and TARGET_ARCH.
For native-xtools this is undesirable since we are building binaries to
run on the host architecture, that can cross compile for the target
architecture.
When building native-xtools for RISC-V, this issue manifests as an invalid
argument for "-march". The compiler is invoked with the target triple of the
host architecture, but the CFLAGS inherited from bsd.cpu.mk are that of the
target architecture.
Reviewed by: imp, bdrewery
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D23838
We handle a number of stale dependency issues on an ad-hoc basis, in
order to support ongoing NO_CLEAN builds. These hacks do not need to
be maintained indefinitely; now remove those for issues that are more
than a year old.
Sponsored by: The FreeBSD Foundation
r359083 introduced a workaround for stale libomp dependencies during a
regular (no -DNO_CLEAN) buildworld. r359088 addressed the reason the
clean step missed libomp, so revert the workaround.
Sponsored by: The FreeBSD Foundation
Apparently make ${CLEANDIR} is leaving stale entries in .depend files;
for now invoke the hacky cleanup in both the -DNO_CLEAN and normal
(no -DNO_CLEAN) cases.
In collaboration with: dim
Sponsored by: The FreeBSD Foundation
The new liblua will be used in a forthcoming import of kyua.
Reviewed by: kevans
Obtained from: CheriBSD
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D24090
We have ad-hoc stale dependency handling in Makefile.inc1 to handle the
cases where file extensions change, but it appears that some cases are
not functional. Add a note when about to clean stale deps to help
when investigating failure reports.
Sponsored by: The FreeBSD Foundation
After r325072 stale lib32 dependencies were not remooved. A more
holistic approach is needed to address this but for the immediate issue
(-DNO_CLEAN builds across r358851) just readd the explicit lib32 path.
Reported by: dim
Sponsored by: The FreeBSD Foundation
The openmp 10.0.0 import renamed one .c file to .cpp, and this is
something our dependency system does not handle correctly. Add another
ad-hoc cleanup to get rid of the stale dependency.
PR: 244251
MFC after: 6 weeks
X-MFC-With: 358851
autofs was introduced with FreeBSD 10.1 and is the supported method for
automounting filesystems. As of r296194 the amd man page claimed that it
is deprecated. Remove it from base now; the sysutils/am-utils port is
still available if necessary.
Discussed with: cy
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Now that we no longer have GCC 4.2.1 in the tree and can assume FreeBSD
is being built with a C++11 compiler available, we can use BSDL dtc
unconditionally and retire the GPL dtc.
GPL dtc now has FreeBSD CI support via Cirrus-CI to help ensure it
continues to build/work on FreeBSD and is available in the ports tree
if needed.
The copy of (copyfree licensed) libfdt that we actually use is in
sys/contrib/libfdt so the extra copy under contrib/dtc/libfdt can be
removed along with the rest of the GPL dtc.
Reviewed by: kevans, ian, imp, manu, theraven
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23192
LLVM's libunwind is used on all FreeBSD-supported CPU architectures and
is a required component.
Reviewed by: brooks (earlier)
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23123
As described in Warner's email message[1] to the FreeBSD-arch mailing
list we have reached GCC 4.2.1's retirement date. At this time all
supported architectures either use in-tree Clang, or rely on external
toolchain (i.e., a contemporary GCC version from ports).
GCC 4.2.1 was released July 18, 2007 and was imported into FreeBSD later
that year, in r171825. GCC has served us well, but version 4.2.1 is
obsolete and not used by default on any architecture in FreeBSD. It
does not support modern C and does not support arm64 or RISC-V.
Thanks to everyone responsible for maintaining, updating, and testing
GCC in the FreeBSD base system over the years.
So long, and thanks for all the fish.
[1] https://lists.freebsd.org/pipermail/freebsd-arch/2020-January/019823.html
PR: 228919
Reviewed by: brooks, imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23124
Summary:
With COMPILER_FREEBSD_VERSION, we use a numeric value that we bump each
time we make a change that requires re-bootstrapping, but with the
linker variant, we instead take the entire part after "FreeBSD", as in
this example version output:
LLD 9.0.1 (FreeBSD c1a0a213378a458fbea1a5c77b315c7dce08fd05-1300006) (compatible with GNU linkers)
E.g., LINKER_FREEBSD_VERSION is currently being set to
"c1a0a213378a458fbea1a5c77b315c7dce08fd05-1300006". This means that
*any* new upstream lld version will cause re-bootstrapping.
We should only look at the numerical field we append after a dash
instead. This review attempts to make it so.
The only thing I am not happy about is the post-processing of awk output
in Makefile.inc1. I notice that our awk does not have gensub(), so it
can't substitute a numbered sub-regex with \1, \2, etc. Suggestions
welcome. :)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D23691
I was overly agressive about removing the entire comment. It was still
valid, except the part about being only for some architectures.
Reviewed by: emaste
Differenial Revision: https://reviews.freebsd.org/D23523
The sparc64 architecture is being removed from FreeBSD 13, starting
now. This removes it from the top level only. It is the only
architecture that didn't see substantial work after the call to get
things working with the external toolchain.
All of the in-tree architectures not supported by in-tree binutils are
supported by lld, so the condition is now always false. It also
didn't fully work since the external binutils are installed into a
directory that uses the host's OS version, not the target OS version.
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D23294
Compressing .txz packages can be rather slow, and speed is likely more
important than disk space during development. Allow package format to
be set via PKG_FORMAT make variable.
Reviewed by: bapt
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23257
Rather than invoking `pkg config ABI` repeatedly.
Reviewed by: manu
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D23255
${WORLDTMP}/legacy/usr/libexec will only have libexec/ bits that we've
pushed as bootstrap tools, so this is generally safe to include prior to
PATH. The following are the ramifications of this change:
- BPATH addition gets us at least bootstrap flua in WMAKEENV path for
buildenv, for those earlier systems where it's bootstrapped still
- Reworked the sysent target to just set PATH and let it get worked out in
src.lua.mk or individual sysent makefiles -- this gives us back the
ability to overwrite LUA_CMD and use a different/external lua for these
targets. sysent can also now work cleanly in buildenv.
- tools/build/Makefile will now symlink the host flua into build's host
tools so that the above can work without needing to add the host's
/usr/libexec explicitly into TMPPATH.
Reviewed by: arichardson, brooks, imp (all slightly earlier version)
Differential Revision: https://reviews.freebsd.org/D22464
LLVM's libunwind is used for all archs, as of r356514. As GCC 4.2.1
will soon be removed, and with it the GNU unwinder, start simplifying
the prereq/startup lib logic in Makefile.inc1. From here if there are
any unwinder bugs (on any arch) the path foward is to fix LLVM's
libunwind.
For libssp.so, rebuild stack_protector.c with FORTIFY_SOURCE stubs that just
abort built into it.
For libssp_nonshared.a, steal stack_protector_compat.c from
^/lib/libc/secure and massage it to maintain that __stack_chk_fail_local
is a hidden symbol.
libssp is now built unconditionally regardless of {WITH,WITHOUT}_SSP in the
build environment, and the gcclibs version has been disconnected from the
build in favor of this one.
PR: 242950 (exp-run)
Reviewed by: kib, emaste, pfg, Oliver Pinter (earlier version)
Also discussed with: kan
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D22943
The freebsd-binutils and freebsd-gcc* packages install toolchain
makefiles to /usr/share/toolchains rather than LOCALBASE.
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D22985
TARGET=arm now defaults to TARGET_ARCH=armv7
TARGET_ARCH=arm is no longer valid.
Bump __FreeBSD_version to 1300073
Tested with make universe. Any stale LINT-V5 config files remaining in the tree
will fail the universe build. However, LINT-V5 was removed in r355119.
This retirement has been planned since last summer. The armv5 port is fragile:
it works OK for some peeople, and fails badly for others. There's a number of
subtle bugs in busdma, pmap and other MD parts of thee system that present
themselves under load or in unusual circumstances (like fsck after a
crash). stable/8, branched 10 years ago, was the last reliable release. Since
the support burden is larger then the benefit, the consensus view is armv5
should be removed from the tree.
Discussed with: arm@ mailing list and arm developer community.
The warning was added in r289728 (over four years ago) and at that time
NO_CLEAN was already the correct spelling for over a decade.
Make NOCLEAN an error as the next step to removing these backward
compatibility shims.
This is due to LLD_REVISION_STRING being renamed to LLD_REVISION in
r351442 and the value being moved to another location in r351965.
`make test-system-linker` can be used to see the values being used here.
Reported by: ler
flua is bootstrapped as part of the build for those on older
versions/revisions that don't yet have flua installed. Once upgraded past
r354833, "make sysent" will again naturally work as expected.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D21894
MK_CLANG_IS_CC controls installing links for GCC, not just clang. Set
MK_CLANG_IS_CC to the value of MK_CLANG_BOOTSTRAP. This will leave it
as "no" if no bootstrap compiler is being built or GCC 4.2.1 is being
used as the bootstrap compiler, and "yes" if clang is being used as
the bootstrap compiler.
Submitted by: bdrewery (kind of, he suggested this on IRC while I was
testing the original patch)
Reviewed by: kevans, imp
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22350
This ensures that a bootstrap clang compiler is always installed as cc
in WORLDTMP. If it is only installed as 'clang' then /usr/bin/cc is
used during the build instead of the bootstrap compiler.
Reviewed by: imp
MFC after: 1 month
Sponsored by: DARPA
Differential Revision: https://reviews.freebsd.org/D22332
Previously we checked for only BINUTILS_BOOTSTRAP as a broken option
and suggested installing the binutils package. This was originally done
for arm64 where we used the in-tree Clang with external binutils package.
Add a case to the warning to suggest instead the full xtoolchain package
if we have no in-tree compiler either.
Differential Revision: https://reviews.freebsd.org/D21851
Alter bsd.compat.mk to set MACHINE and MACHINE_ARCH when included
directly so MD paths in Makefiles work. In the process centralize
setting them in LIBCOMPATWMAKEENV.
Alter .PATH and CFLAGS settings in work when the Makefile is included.
While here only support LIB32 on supported platforms rather than always
enabling it and requiring users of MK_LIB32 to filter based
TARGET/MACHINE_ARCH.
The net effect of this change is to make Makefile.libcompat only build
compatability libraries.
Changes relative to r354449:
Correct detection of the compiler type when bsd.compat.mk is used
outside Makefile.libcompat. Previously it always matched the clang
case.
Set LDFLAGS including the linker emulation for mips where -m32 seems to
be insufficent.
Reviewed by: imp, kib (origional version in r354449)
Obtained from: CheriBSD (conceptually)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22251
Alter bsd.compat.mk to set MACHINE and MACHINE_ARCH when included
directly so MD paths in Makefiles work. In the process centralize
setting them in LIBCOMPATWMAKEENV.
Alter .PATH and CFLAGS settings in work when the Makefile is included.
While here only support LIB32 on supported platforms rather than always
enabling it and requiring users of MK_LIB32 to filter based
TARGET/MACHINE_ARCH.
The net effect of this change is to make Makefile.libcompat only build
compatability libraries.
Reviewed by: imp, kib
Obtained from: CheriBSD (conceptually)
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D22251
Add lib/libzstd to _elftoolchain_libs
tools/build/Makefile needs to create the install dir for libzstd
Since this would make the line too long, rework to use a list
in one per line format (easier to add in future)
and dispense with the .for loop
Reviewed by: emaste bapt
Differential Revision: https://reviews.freebsd.org/D220134
opensolaris_atomic.S is now only used on i386 with opensolaris_atomic.c
used on other platforms. After r353381 it doesn't exist on those
platforms so the stale dependency would result in a build error.
r353408 addressed this issue for cddl/lib/libzpool, but it persisted
with the opensolaris and zfs modules.
This should change nothing for kernel configurations at the standard
locations in the source tree. However, if KERNCONFDIR is used to
specify a custom location for a kernel configuration file (e.g., out of
tree), then both the custom location and the standard location, in this
order, will be used as include paths for config(8). This will allow the
kernel configuration to include files from both locations.
Reviewed by: bdrewery
MFC after: 16 days
Differential Revision: https://reviews.freebsd.org/D22057
opensolaris_atomic.S is now only used on i386 with opensolaris_atomic.c
used on other platforms. After r353381 it doesn't exist on those
platforms so the stale dependency would result in a build error.
WITHOUT_LOCAL_MODULES can be set to disable LOCAL_MODULES for native
builds. WITH_LOCAL_MODULES can be set to leave it enabled for cross
builds.
This does not use a knob in kern.opts.mk because the options framework
does not currently support options whose default varies on the build
type. I discussed a few options there with Warner (e.g. maybe having
a tri-state where the default value is "auto" and having Makefile.inc1
apply logic when MK_LOCAL_MODULES is set to "auto"), but Warner ok'd
this approach for now until a better solution is implemented.
Requested by: many
Reviewed by: imp (in person at EuroBSDCon)
Differential Revision: https://reviews.freebsd.org/D21608
memfd_create is effectively a SHM_ANON shm_open(2) mapping with optional
CLOEXEC and file sealing support. This is used by some mesa parts, some
linux libs, and qemu can also take advantage of it and uses the sealing to
prevent resizing the region.
This reimplements shm_open in terms of shm_open2(2) at the same time.
shm_open(2) will be moved to COMPAT12 shortly.
Reviewed by: markj, kib
Differential Revision: https://reviews.freebsd.org/D21393
Note that old pkg will failed to build after this. A recent ports tree (one
providing pkg 1.12+) is required to build. Older already built pkg, should
continue working as expected
PR: 238797
Exp run by: antoine
Reviewed by: cem
Approved by: cem
Differential Revision: https://reviews.freebsd.org/D20752
Currently APLHA packages are treated as CURRENT or STABLE versions,
resulting in e.g. 13.0.s20190615125609. This version number is indeed
different from the next version number but ALPHA2 would be nicer IMO.
For the BETA, PRERELEASE and RC phases the packages are versioned the
same as for releases, so 11.3-BETA1 is 11.3 and so is 11.3-RC1, meaning
that pkg cannot easiliy upgrade from the former the next. This happened
on my Raspberry Pi which runs pkgbase.
Submitted by: rene
Approved by: manu
Event: Berlin hackathon 2019
Differential Revision: https://reviews.freebsd.org/D20651
the followup stopgap change, because I don't think it's a correct. I still
need to figure out where to stick it in. In cannot be in Makefile.inc1
and it cannot be in etc/Makefile from the looks of it to avoid
chicken-and-egg problem.
install -> ${INSTALL}
mtree -> ${MTREE_CMD}
services_mkdb -> ${SERVICES_MKDB_CMD}
cap_mkdb -> ${CAP_MKDB_CMD}
pwd_mkdb -> ${PWD_MKDB_CMD}
kldxref -> ${KLDXREF_CMD}
If you do custom FreeBSD builds you may want to override those
in some cases.
Sponsored by: Sippy Software, Inc.
libc was picked as the destination location for these because of the syscalls
that use these files as the lowest level place they are referenced.
Approved by: will (mentor), rgrimes, manu
Differential Revision: https://reviews.freebsd.org/D16728
uname is always rebuild on FreeBSD so use this as ABI_FILE for pkg when
building pkg for pkgbase.
pkg uses uname too as default ABI_FILE as of commit d8bbf980b7f6f424fb7cc672c23ab2dfc82b6599
d8bbf980b7
Discussed with: bapt
MFC after: 1 week
The wpa update added some source files with the same name as a file in
another directory (found via .PATH in the previous version). Having a
stale entry in a .depend file means the new file won't be built, so test
for this case and if found remove all of wpa's dependency files.
MFC with: r341759
Sponsored by: The FreeBSD Foundation
newvers.sh runs mkfifo which did not exist before this change.
However, I didn't notice before because it is run from a function
where a missing command does cause a noticeable failure.
Reviewed By: emaste, markj
Differential Revision: https://reviews.freebsd.org/D18377
We were still building it from Makefile.inc1. Disable it there so we don't
try to build the GNU crtbegin/crtend when the BSD version was asked for.
PR: 233733
Reported by: lwhsu
Reviewed by: emaste
MFC with: r339738
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D18428
Without this change I got the following error:
clang-7: error: no such file or directory: '..../lib/libc/amd64/string/bzero.S'
Reviewed By: mjg
Differential Revision: https://reviews.freebsd.org/D18031
list and remaining references from the script used to create the
MANIFEST file used by bsdinstall(8).
No MFC is planned at this time.
Sponsored by: The FreeBSD Foundation
The sysent target is useful when changing makesyscalls.sh, when
making paired changes to syscalls.master files, or in a future where
freebsd32 sysent entries are built from the default syscalls.master.
Reviewed by: bdrewery
Obtained from: CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D17899
Building with a strict $PATH (without inheriting from the parent
environment) still causes build failures in some workflows/environemnts
that I have not yet tested.
I will try to bring this back once these issues have all been resolved
since it is actually extremely useful in tracking broken dependencies
and wrong assumptions about the build environemt.
Discussed With: brooks
It is only present on amd64/i386 systems which breaks buildworld on
other hosts. In fact there is no need to add it to the bootstrap tools
list since it is already included in the cross-tools phase.
However, for cross-tools it was only built if the host and target
architecture didn't match. After this change it is also built when we
are builtin with a strict $PATH.
Reported By: mmel
I missed this case when testing r340157. For now just keep
$PATH when we aren't bootstrapping a compiler so that the build
can find cc/c++/ld without an absolute path.
Reported by: yuripv
It is not necessary to build libelf and libdwarf this early. Furthermore,
when building on Linux/MacOS, m4 will only be built during the bootstrap
tools phase and not be available in $PATH before.
Reviewed By: emaste
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D17800
Inheriting $PATH during the build phase can cause the build to fail when
compiling on a different system due to missing build tools or incompatible
versions somewhere in $PATH. This has cause build failures for us before
due to the jenkins slaves still running FreeBSD 10.
Listing the tools we depend on explicitly instead of just using whatever
happens to be in $PATH allows us to check that we don't accidentally add a
new build dependency.
All tools that do no need to be bootstrapped will now be symlinked to
${WORLDTMP}/legacy/bin and during the build phase $PATH will only contain
${WORLDTMP}. There is also a new variable "BOOTSTRAP_ALL_TOOLS" which can
be set to force compiling almost all bootstrap tools instead of symlinking
them. This will not bootstrap tools such as cp,mv, etc. since they may be
used during the build and for those we should really only be using POSIX
compatible options.
Furthermore, this change is required in order to be able to build on
non-FreeBSD hosts. While the same binaries may exist on Linux/MacOS they
often accept different flags or produce incompatible output.
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D16815
Further to r339946 skip the .error case for lack of in-tree binutils
support when we haven't set the toolchain feature variables.
Discussed with: arichardson
Sponsored by: The FreeBSD Foundation
This will no work when there is no cc in $PATH (which is the case before the
cross-tools stage once we no longer inherit $PATH in $WMAKE).
The variables set by bsd.compiler.mk/bsd.linker.mk are not needed in these
stages so this avoids a little bit of makefile parsing.
Reviewed By: emaste
Approved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D16814
It is more convenient to review old libraries, files, and directories
in order.
Sort check-* after checking for existence of files for efficiency, and
because /usr/lib/debug entries are added while iterating over the list.
Reviewed by: brooks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D17649
When building CheriBSD we have to set XLD/XCC/XCFLAGS on the command line.
This triggers the $XCC != $CC case in bsd.compiler.mk (and the same for LD
in bsd.linker.mk) which causes it to call ${XCC} --version and
${XLD} --version (plus various awk+sed+echo calls) in every subdirectory.
For incremental builds and stages that only walk the source tree this is
often the majority of the time spent in that directory.
By only computing the value of the X_COMPILER_*/X_LINKER_* variables if
_WANT_TOOLCHAIN_CROSS_VARS is set we can reduce the number of cc/ld calls
to once per build stage instead of once per recursive make.
With this change (and no changes to the sources) the `make includes` stage
now takes 28 seconds at -j1 instead of 86 seconds.
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D17046
Our dependency tracking cannot directly cope with certain source tree
changes, particularly with respect to removing or moving source files or
replacing generated files. We have a collection of ad-hoc workarounds
to handle these cases. As there is a (small) build-time cost inherent
in these workarounds, we do not want to keep them indefinitely. Thus,
remove workarounds from 2017.
Sponsored by: The FreeBSD Foundation
r339348 switched bcopy from .s to .c. Add ad-hoc dependency cleanup
as done for similar cases.
Approved by: re (kib)
Sponsored by: The FreeBSD Foundation
For OpenSSL 1.1.1 compatibility.
In Makefile.inc1 add (to the existing similar cases) a hack to handle
dependencies across the migration.
Reviewed by: jhb
Approved by: re (gjb)
Sponsored by: The FreeBSD Foundation.
Differential Revision: https://reviews.freebsd.org/D17481
Update the BOOTSTRAPPING check for libelf to require the fix for
mips64el object files committed in r338478 and re-enable kernel
modules in the MALTA64EL config file.
Reviewed by: emaste
Approved by: re (gjb)
Differential Revision: https://reviews.freebsd.org/D17054
During the build it is only used by share/ctypedef and share/colldef
which will not be built if ${MK_LOCALE} == "no". This saves a tiny bit
of time when building without locales.
Approved By: jhb (mentor)
This has two advantages:
1) We no longer create lots of empty directories that are not needed
2) This is a requirement for building on non-FreeBSD hosts since mtree will
only exist after the bootstrap-tools phase there.
Aproved By: jhb (mentor)
Differential Revision: https://reviews.freebsd.org/D16773
Some background: in the GSoC project, libbe/Makefile lived in lib/libbe. I
created projects/bectl branch, maintained the above for all of five
minutes before I misread Makefile.inc1 and decided that it couldn't possibly
build outside of cddl/, so I kicked the Makefile out into the cddl/ build
and all was good. The misreading was of the bit where .WAIT is added to
SUBDIR after lib, libexec but prior to building bin and cddl *only during
the install targets*, which is the critical part.
Fast forward- buildworld was still broken in my branch unbeknownst to me
because I didn't nuke my OBJDIR. Combing through Makefile.inc1 eventually
revealed the necessary magic to make sure that libbe's dependencies are
specified well enough, and it becomes clear what needs done to make a
non-cddl/ build work. This is an interesting prospect, because the build
split is kind of annoying to work with.
IGNORE_PRAGMA is added to avoid dropping WARNS by one more. This was
previously pulled in via cddl/Makefile.inc.
In the create-world-packages target we manually piece this together (unless
it is undefined), without the DISTDIR. Normally DISTDIR is empty (unset) and
no one notices. Now DISTDIR is a well known long-standing PORTS environment
variable and if that is set in the local environment the path to METALOG
is wrong as it no longer is ${DESTDIR}/METALOG.
Long-term we should start to avoid "publicly well known" names for global
variables, for now just piece ${DISTDIR} in as well. This allows
create-world-packages to continue if DISTDIR is set in the env.
There are several scripts and targets solely used to generate install
media, make sure DB_FROM_SRC is used in that case in order to prevent
checking the host database, which is irrelevant when generating
install binaries.
Sponsored by: Citrix Systems R&D
PR: 230459
Reviewed by: gjb
Differential revision: https://reviews.freebsd.org/D16638
- Missing include path
- Fully specify libzfs's dependencies (except for deps pulled in by other
deps) in Makefile.inc1
- Drop WARNS back down to 2 for libbe(3). I do this with much hesitation,
but the libzfs headers are apparently a hot warning-filled mess as far as
GCC 4.2 is concerned.
libl is needed for config(8), which is a bootstrap-tool. It is possible to
build a system WITHOUT_TOOLCHAIN to exclude lex and thus, libl. We still
need to support building from this kind of host, though.
While here, group the config(8) dependencies together and add a small
explanation. These can likely both be scoped more clearly, but this will
need some further investigation.
Reported by: rgrimes (not WITHOUT_TOOLCHAIN, but provoked investigation)
MFC after: immediately
distributeworld is used to generate install media, so it makes no
sense to check the host database since the install media can be
generated from any box, regardless of the version of FreeBSD it's
running.
Sponsored by: Citrix Systems R&D
Reviewed by: ian, gjb
Differential revision: https://reviews.freebsd.org/D16507
r335653 flipped the order in which hints/env files are concatenated to match
the order in which vars are processed by the kernel. This is the other
hammer to drop.
Use nv(9) to de-dupe entries within a single `hint` or `env` file, using the
latest value specified for a key. This leaves some duplicates if a variable
is specified in multiple hint/env files or via `envvar` in a kernel config,
but the reversed order of concatenation (from r335653) makes this a
non-issue as the latest-specified version will be seen first.
This change also silently rewrote hint bits to use the same sanitization
process that ian@ wrote for r335642. To the kernel, hints and env vars are
basically the same thing through early boot, then get merged into the
dynamic environment once kmem becomes available and the dynamic environment
is created. They should be subjected to the same restrictions.
libnv has been added to -legacy for the time being to support the build of
config(8) with the new cnvlist API.
Tested with: universe (11 host & 12 host)
MFC after: 1 month
The build of this would have MK_LLVM_TARGET_ALL=yes for bootstrap-tools
but MK_LLVM_TARGET_ALL=no for cross-tools and thus would rebuild between
the two.
MFC after: 2 weeks
X-MFC-with: r335707
Sponsored by: Dell EMC
Currently the mtree calls in Makefile.inc1 all change the directory owner
to match the spec file. However, we should not be doing this during
distributeworld if -DNO_ROOT is passed. Additionally, when creating the
WORLDTMP directory hierachy there is no need to change the owner to root so
we now always pass the -W flag when populating WORLDTMP.
This is also required for building FreeBSD on Linux/Mac since the required
groups/users will not exist there which is how I discovered this issue.
Reviewed By: emaste, bdrewery, imp
Approved By: brooks (mentor)
Differential Revision: https://reviews.freebsd.org/D14185
The xtoolchain GCC packages have not required these flags since ports
commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched
in r335716 and r335717 to correctly honor --sysroot when looking for
includes and libraries.
Reviewed by: bdrewery
Sponsored by: DARPA / AFRL
Differential Revision: https://reviews.freebsd.org/D16055
Need to handle LLD_BOOTSTRAP separately (for archs like i386).
This would be much better off with an off-by-default option like
SHARED_TOOLCHAIN that universe force-enabled. Then a normal buildworld
would store the toolchain there if enabled and otherwise in WORLDTMP
with only the 1 arch selected.
MFC after: 3 weeks
Sponsored by: Dell EMC
This will disable the new LLVM_TARGET_ALL option which will only
enable the required target.
This only impacts the bootstrap compiler in WORLDTMP, not the target compiler
that will be installed.
MFC after: 2 weeks
Reviewed by: sbruno, dim (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D16021
LLVM_TARGET_* will auto be set based on LLVM_TARGET_ALL and MK_CLANG.
If LLVM_TARGET_ALL is disabled, during a cross-build, then SYSTEM_COMPILER
and SYSTEM_LINKER are auto disabled.
This option should be used by users rather than the per-arch LLVM_TARGET
options as it is simpler to maintain for them should the supported
target list change.
MFC after: 2 weeks
Reviewed by: sbruno, dim
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D16020
Rather then combining hardlink creation for the geom(8) binary with
shared library build, move libraries to src/lib/geom so they are
built and installed normally. Create a common Makefile.classes
which is included by both lib/geom/Makefile and sbin/geom/Makefile
so the symlink and libraries stay in sync.
The relocation of libraries allows libraries to be build for 32-bit
compat. This also reduces the number of non-standard builds in
the system.
This commit is not sufficent to run a 32-bit /sbin/geom on a 64-bit
system out of the box as it will look in the wrong place for libraries
unless GEOM_LIBRARY_PATH is set appropriatly in the environment.
Reviewed by: bdrewery
Sponsored by: DARPA, AFRL
Differential Revision: https://reviews.freebsd.org/D15360
We always install ELF Tool Chain's elfcopy as objcopy, so to avoid
confusion rename the src directory containing our reach-over Makefile
to match.
Requested by: jhb
Sponsored by: The FreeBSD Foundation
This works similar to WITH_SYSTEM_COMPILER added in r300354. It only
supports lld via WITH_LLD_BOOTSTRAP.
When both SYSTEM_COMPILER and SYSTEM_LINKER logic passes then libclang
will not build in cross-tools. If either check fails though then
libclang is built.
The .info is reworked to notify when libclang will be built since if
either clang or lld needs to be rebuilt, but not the other, the
notification can lead to confusion on why "clang is building".
-fuse-ld= is not used with this method so some combinations of compiler
and linker are expected to fail.
A new 'make test-system-linker' target is added to see the logic results.
Makefile.inc1:
CROSS_BINUTILS_PREFIX support had to be moved higher up so that XLD
could be set and MK_LLD_BOOTSTRAP disabled before checking SYSTEM_LINKER
logic as done with SYSTEM_COMPILER. This also required moving where
bsd.linker.mk was read since XLD needs to be set before parsing it. This
creates a situation where src.opts.mk can not test LINKER_FEATURES or
add LLD_BOOTSTAP to BROKEN_OPTIONS.
Reviewed by: emaste (earlier version)
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15894
MK_LLD is for the installed lld while MK_LLD_BOOTSTRAP is for the build
tool. For WITH_SYSTEM_LINKER it is necesarry to separate the logic of
these two. When building libllvm TOOLS_PREFIX will be defined and
MK_LLD_BOOTSTRAP should be checked instead.
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15837
LLD_BOOTSTRAP (build) is independent of LLD_IS_LD (installed) so they
should not be based on each other.
This is related to upcoming WITH_SYSTEM_LINKER work.
Reviewed by: emaste
Sponsored by: Dell EMC
Differential Revision: https://reviews.freebsd.org/D15836
It is XCC used during the build of target binaries that replaces the
bootstrap compiler.
Also slightly tweak style.
MFC after: 2 weeks
Sponsored by: Dell EMC
This could lead to 'sh: head: not found' warnings which were a symptom
of running 'ld --version' during installworld. This was only happening
with XCC or XLD set. It is intended that cc and ld do not run during
installworld. The metadata for these are already stored in
compiler-metadata.mk added in r316794.
This also removes redundant CROSSENV additions that were for
WITH_SYSTEM_COMPILER, WITHOUT_CROSS_COMPILER, and WITHOUT_TOOLCHAIN
which all don't have a cc or ld in their PATH during install.
Reported by: Mark Millard
MFC after: 2 weeks
Sponsored by: Dell EMC
Aligns the build with the FreeBSD traditional approach to not build in
contrib/, and to track inter-dependencies between libraries.
With help from: bdrewery
Reviewed by: bdrewery, hselasky
Sponsored by: Mellanox Technologies
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D15648
vendor provided pmu-events tables and sundry cleanups.
The vendor pmu-events tables provide counter descriptions, default
sample rates, event, umask, and flag values for all the counter
configuration permutations. Using this gives us:
- much simpler kernel code for the MD component
- helpful long and short event descriptions
- simpler user code
- sample rates that won't overload the system
Update man page with newer sample types and remove unused sample type.
vendor provided pmu-events tables and sundry cleanups.
The vendor pmu-events tables provide counter descriptions, default
sample rates, event, umask, and flag values for all the counter
configuration permutations. Using this gives us:
- much simpler kernel code for the MD component
- helpful long and short event descriptions
- simpler user code
- sample rates that won't overload the system
Update man page with newer sample types and remove unused sample type.
Squashed commit of the following:
commit 4459d43eff815bec08ccc5533dbe5de846f03128
Author: Matt Macy <mmacy@mattmacy.io>
Date: Sat May 26 00:06:31 2018 -0700
libpmc: fix pmu function signatures for non amd64
commit a2cb8bbc586c65d41f9b291430a2261ec67b59fe
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 22:38:11 2018 -0700
pmcstat: fix indentation of usage
commit f686954b15ff56a833ac80404898977cb80a265b
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 22:19:49 2018 -0700
pmclog(3): add callchain and pmcallocatedyn, remove pcsample
commit 73e13a0d2e9498c81c150d14d022050cee7511bb
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 22:19:00 2018 -0700
pmclog.h: GC pcsample field
commit 3e93ffd65da641fa657539dad3c48e281f8b5798
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 22:05:57 2018 -0700
hwpmc: make Intel core CPUs use external event tables
commit 634f5fae1e1644ac324003136c66cd9c619d1c93
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 22:00:06 2018 -0700
pmclog: update log record types, bump PMC_MAJOR
- explicitly make log record types a multiple of 8 bytes
- hook in pmu event types for pmc_allocate records
- remove references to no longer PCSAMPLE record
commit 83d84fcd2d65bdf6ddcb2e155a22f0cfa2a9c225
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 21:52:10 2018 -0700
libpmc: add support for having vendor table driven pmc_allocate
commit 9e6ad63c40c2fce8404847ace5078ca6cb33a736
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 19:11:33 2018 -0700
hwpmc_core: add accessors for EVSEL & UMASK, make IAP_UMASK useful to user
commit 859dceb93daa6419a48c794db99b6758e5b041c9
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 19:09:45 2018 -0700
pmcstat: update usage and man page as well as make -L consistent with pmccontrol
commit 79c7d8597e28c2eb13f5f9113e65ec2792ca57b1
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 18:07:03 2018 -0700
pmu_util: add support for all current intel event keywords
commit d8089c7f6a6c8527f38324252b1ffb47004694c6
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 17:45:00 2018 -0700
add description for new arguments
commit 058336740bab53c62ec88a3a026ea848cf3878c6
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 17:38:15 2018 -0700
libpmc: move pmu_events table and pmu_utils out of libpmcstat so that they can be used by pmc_allocate
commit 049b66b382e2f833c3f47bc8df9e750cb265709f
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 16:12:41 2018 -0700
pmcstat: hook pmu_events counter description utility routines in
commit f5e01e7b37a691dc045e1aa16b3ebdd162515de8
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 16:11:59 2018 -0700
pmu_events: add utility routines for listing counters and their descriptions
commit cba4d4f8907f772279f86f18f915e0d74d33ac56
Author: Matt Macy <mmacy@mattmacy.io>
Date: Fri May 25 16:09:50 2018 -0700
pmu-events: expand out skylake regex to simplify string matches
r307825 and r333017 disallow building FreeBSD-HEAD from 9.x or 10.x
versions that have some clang issues. The minimum supported Subversion
revisions and osreldates containing the fix are:
Version Min Rev osreldate
9.x r286035 903509
10.x r286033 1002501
9.3 is the final 9.x release and does not contain the r286035 fix.
10.3 is the first 10.x release with the fix. Thus, in practice 10.3 is
the oldest release that can build HEAD.
Although it may still be possible to build HEAD from an up-to-date
stable/9 it's not worth maintaining the special case when the branch
itself is unsupported and there are no usable releases from that branch.
Old UPDATING entries can be removed and the Clang warning in UPDATING
may be updated, in a future commit.
Approved by: imp
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D15209
