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
