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
