Makefile.inc1: Don't force LLVM_BINUTILS off for cross-tools

Because of this setting we were still using ELF Tool Chain tools for
buildworld. The sets of binary utilities are largely equivalent and

Makefile.inc1: Don't force LLVM_BINUTILS off for cross-tools

Because of this setting we were still using ELF Tool Chain tools for
buildworld. The sets of binary utilities are largely equivalent and
this went unnoticed after commit 1cae7121c667 ("Enable LLVM_BINUTILS
by default").

This was discovered recently because ELF Tool Chain objcopy produces
standalone debug files without phdrs and this caused an issue with a
3rd party ELF parser [1]. Remove the forced setting so that we use
LLVM's binutils to build the system.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33876

Reviewed by: imp, jhb
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D55650

show more ...

Run `make obj` before running `make test-includes`

Before this change, `make test-includes` (run as part of buildworld)
would place test files in the current directory, which would clutter up
git cl

Run `make obj` before running `make test-includes`

Before this change, `make test-includes` (run as part of buildworld)
would place test files in the current directory, which would clutter up
git clones. Run `make obj` beforehand to ensure that the files are put
in `${.OBJDIR}` instead of `${.CURDIR}`. This helps cut down on the
noise significantly when running commands like `git status`.

MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55499

show more ...

packages: Don't create empty packages

If a package plist only contains directories, but no files, do not
create the package.

This fixes an issue where setting "package=foo" in mtree causes the
"foo

packages: Don't create empty packages

If a package plist only contains directories, but no files, do not
create the package.

This fixes an issue where setting "package=foo" in mtree causes the
"foo" package to always be created, even if nothing else installs in
that package, because the mtree entry is always added to the plist.

This most often happens:

* With architecture-specific directories, because mtree can't install
a directory conditionally based on architecture, and

* With packages that are completely empty when a particular src.conf
knob is disabled, because mtree will still create the directories.

Although it's theoretically possible that we might want to create a
package that only contains directories, there are no such packages
today.

MFC after: 2 weeks (stable/15 only)
Reviewed by: manu, des
Differential Revision: https://reviews.freebsd.org/D55412
Sponsored by: https://www.patreon.com/bsdivy

show more ...

Makefile.inc1: Don't mark GCC broken for riscv64

Reviewed by: mhorne
Differential Revision: https://reviews.freebsd.org/D54969

native-xtools: use static LLVM libraries

Set the MK_LLVM_LINK_STATIC_LIBRARIES knob to "yes" when building the
native-xtools target. This reverts to the behaviour prior to
2e47f35be5dc.

This avoids

native-xtools: use static LLVM libraries

Set the MK_LLVM_LINK_STATIC_LIBRARIES knob to "yes" when building the
native-xtools target. This reverts to the behaviour prior to
2e47f35be5dc.

This avoids a build failure that occurs otherwise, where compilation
fails looking for a libllvmprivate.so that was not built.

It is unclear if this addresses the issue in all instances---some
replies in the PRs indicate otherwise. Still, some report success, and
in my own testing this fixed creation of a cross-compiled poudriere
jail. Commit this while we continue to investigate...

PR: 286710, 291409
Tested by: marck, rdunkle@smallcatbrain.com
Reviewed by: emaste
MFC after: 3 days
Fixes: 2e47f35be5dc ("Convert libllvm, libclang and liblldb into private shared libraries").
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D54815

show more ...

Makefile*: remove powerpcspe

As reported on the freebsd-announce mailing list[1] FreeBSD is
continuing to retire 32-bit support. Remove powerpcspe from build
infrastructure.

[1] https://lists.free

Makefile*: remove powerpcspe

As reported on the freebsd-announce mailing list[1] FreeBSD is
continuing to retire 32-bit support. Remove powerpcspe from build
infrastructure.

[1] https://lists.freebsd.org/archives/freebsd-announce/2024-February/000117.html

Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Reviewed by: jhibbits, emaste
Pull request: https://github.com/freebsd/freebsd-src/pull/1914

show more ...

Makefile: Update doxygen requirements

MFC after: 3 days
Reviewed by: imp, ziaee
Signed-off-by: Minsoo Choo <minsoochoo0122@proton.me>
Closes: https://github.com/freebsd/freebsd-src/pull/1869

Makefile.inc1: Fix INSTALLEXTRAKERNELS for one-kernel case

If BUILDKERNELS contains a single kernel, and NO_INSTALLEXTRAKERNELS=no,
then ${BUILDKERNELS:[2..-1]} returns the first kernel in the list

Makefile.inc1: Fix INSTALLEXTRAKERNELS for one-kernel case

If BUILDKERNELS contains a single kernel, and NO_INSTALLEXTRAKERNELS=no,
then ${BUILDKERNELS:[2..-1]} returns the first kernel in the list and
that kernel ends up in both INSTALLKERNEL and INSTALLEXTRAKERNELS.

This breaks the package build because it means we generate that package
twice, once with an incorrect install path of /boot/kernel.NAME instead
of /boot/kernel.

Only set INSTALLEXTRAKERNELS if we're building at least two kernels.

Fixes: 2c0e9a76c1ce ("Makefile.inc1: Make NO_INSTALLKERNEL less of a hack")
Reviewed by: jrtc27
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D54539

show more ...

Makefile.inc1: Allow safe installkernel with pkgbase

Commit 74a6bb524e5b added a check to install{world,kernel} to avoid
people accidentally running this on pkgbase systems and leaving their
system

Makefile.inc1: Allow safe installkernel with pkgbase

Commit 74a6bb524e5b added a check to install{world,kernel} to avoid
people accidentally running this on pkgbase systems and leaving their
system broken. This had two issues:

(1) The warning was not sufficiently scary, leading people to think
this was safe to do as long as they set DESTDIR=/.

(2) The installkernel check was too strict, and prevented installing
kernels that don't conflict with packaged kernels.

Fix (1) by rewording the warning to be scarier, and while here, add
two new variables (ALLOW_PKGBASE_INSTALL{WORLD,KERNEL}) which could
be set in /etc/make.conf for people who want to break their systems
by default.

Fix (2) by improving the installkernel check to see if the kernel(s)
we're actually installing are packaged. This means a new kernel can
be installed to /boot/kernel as long as there's no packaged kernel
installed there. This check understands INSTKERNNAME, so if there
is a packaged kernel in /boot/kernel, the new kernel can still be
installed using INSTKERNNAME=testkernel (or whatever).

MFC after: 2 weeks
Reported by: christos, jhb, others
Reviewed by: emaste, christos (previous version)
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D54346

show more ...

Makefile.inc1: Indicate that no-clean builds are on by default

PR: 292130

depend-cleanup: Force a clean build when options change

Similar to the build epoch check, cache a list of source options in the
object tree, and force a clean build if the cached list does not match

depend-cleanup: Force a clean build when options change

Similar to the build epoch check, cache a list of source options in the
object tree, and force a clean build if the cached list does not match
the current list, after filtering out options which are known not to
affect the build (e.g. CLEAN, TESTS, WARNS).

This also adds a DEPEND_CLEANUP option (which defaults to yes unless
the CLEAN option is set) which can be used to skip depend-cleanup for
faster incremental builds.

MFC after: 1 week
Reviewed by: imp
Differential Revision: https://reviews.freebsd.org/D52011

show more ...

Makefile.inc1: Make NO_INSTALLKERNEL less of a hack

Rather than adding a dummy entry which requires everyone to know to skip
it, introduce a new INSTALLEXTRAKERNELS which contains the set of
kernels

Makefile.inc1: Make NO_INSTALLKERNEL less of a hack

Rather than adding a dummy entry which requires everyone to know to skip
it, introduce a new INSTALLEXTRAKERNELS which contains the set of
kernels to install as kernel.KERNCONF.

Reviewed by: ivy
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54291

show more ...

zfs: world changes after 89f729dcc merge

Remove, unbind and obsolete libuutil and libtpool
Update zfs_configh and zfs_gitrev.h

Makefile.inc1: Fix the libbnxtre dependency target

Reported by: Jenkins
Fixes: 73e8fe62466a ("libpcap: Fix dependency definitions for libpcap")

libpcap: Fix dependency definitions for libpcap

Commit 35dd53a9e132 ("librdmacm/libibverbs: Statically bound libbnxtre.so.1 to rping")
causes a build failure, since src.libnames.mk declares a depenc

libpcap: Fix dependency definitions for libpcap

Commit 35dd53a9e132 ("librdmacm/libibverbs: Statically bound libbnxtre.so.1 to rping")
causes a build failure, since src.libnames.mk declares a depencency on
libbnxtre.so, but the libpcap Makefile and prebuild lib dependencies
were not updated accordingly. Fix the declarations.

Fixes: 35dd53a9e132 ("librdmacm/libibverbs: Statically bound libbnxtre.so.1 to rping")
Reviewed by: ssaxena
Differential Revision: https://reviews.freebsd.org/D54048

show more ...

Use install instead of cp to copy bootstrap tools

We need to preserve modification times on bootstrap tools, but `cp -p`
also tries to preserve flags, which fails if OBJROOT is on NFS. A -N
option

Use install instead of cp to copy bootstrap tools

We need to preserve modification times on bootstrap tools, but `cp -p`
also tries to preserve flags, which fails if OBJROOT is on NFS. A -N
option was added to cp for this purpose, but trying to use that would
break cross-building on hosts that don't have that option. The best
remaining option is `install -p`, which we already assume is present.

PR: 275030
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D53751

show more ...

Makefile.incl1: .WAIT before distribute in etc

In order to make sure that man pages are all installed before we run
makewhatis to generate mandoc.db files, we have long placed etc at the
end of the

Makefile.incl1: .WAIT before distribute in etc

In order to make sure that man pages are all installed before we run
makewhatis to generate mandoc.db files, we have long placed etc at the
end of the list of subdirectories being recursed into by the build.
In order to support installworld -jN, a .WAIT was more recently added
here.

With the recent adoption by the release engineering team of parallel
*release* builds (aka 'make release -jN') it is now also necessary to
add the same .WAIT before recursing for the 'distribute' target, as we
otherwise end up with distribution sets containing incomplete mandoc.db
files.

Reviewed by: bdrewery
PR: 289683
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53533

show more ...

Makefile: Don't allow install{world,kernel} with pkgbase

Using these targets on a pkgbase system will cause the installed system
to become out of sync with the package database, which is almost cert

Makefile: Don't allow install{world,kernel} with pkgbase

Using these targets on a pkgbase system will cause the installed system
to become out of sync with the package database, which is almost certain
to cause issues the next time pkg(8) is used.

To prevent users doing this accidentally, disallow install* if we detect
that FreeBSD-runtime is installed in the target. The check can be
overridden with DESTDIR=/ for users who are sure they want to do this.

MFC after: 3 days
Reviewed by: emaste
Sponsored by: https://www.patreon.com/bsdivy
Differential Revision: https://reviews.freebsd.org/D52879

show more ...

packages: Compress in parallel

The FreeBSD-base pkg repository is currrently dominated by a handful of
large packages: Out of a compressed repository size of ~960 MB, about
160 MB is taken up by the

packages: Compress in parallel

The FreeBSD-base pkg repository is currrently dominated by a handful of
large packages: Out of a compressed repository size of ~960 MB, about
160 MB is taken up by the FreeBSD-src package, 128 MB (on amd64) is
used by the FreeBSD-kernel-generic-dbg package, and 91 MB is used by
the FreeBSD-src-sys package. Consequently, running 'make packages -jN'
provides less benefit than one might hope, as most of the packages
finish building quickly, ultimately leaving the FreeBSD-src package
building by itself for a couple minutes while all the other CPUs are
idle.

Pass -T${PKG_CTHREADS} to the 'pkg create' commands (with a default
of -T0) in order to instruct pkg's zstd compression to use multiple
threads.

Testing on an EC2 r7i.48xlarge instance with -j192, this reduces the
time taken by 'make packages' from 6m17s to 1m39s; package creation
time itself (excluding the initial process of installing into world
and kernel staging directories) dropped from 5m37s to 59s.

Reviewed by: ivy
MFC after: 3 days
Sponsored by: https://www.patreon.com/cperciva
Differential Revision: https://reviews.freebsd.org/D53053

show more ...

Makefile.inc1: Build source packages before sets

To build set-src, we first need to build the source packages. Add a
.ORDER to ensure this happens. Otherwise, in a parallel build, sets
might be bu

Makefile.inc1: Build source packages before sets

To build set-src, we first need to build the source packages. Add a
.ORDER to ensure this happens. Otherwise, in a parallel build, sets
might be built before the src-* packages have finished building, and
set-src will be mysteriously missing.

MFC after: 3 seconds
Reported by: cperciva
Actually diagnosed by: jrtc27
One-line fix by: ivy
Reviewed by: cperciva
Differential Revision: https://reviews.freebsd.org/D53076

show more ...

build: fix ordering of pkgbase targets to get a dtb package reliably

dtb.plist is generated by mtree-to-plist when it processes the kernel
metalog, so we shouldn't try to create dtb packages until t

build: fix ordering of pkgbase targets to get a dtb package reliably

dtb.plist is generated by mtree-to-plist when it processes the kernel
metalog, so we shouldn't try to create dtb packages until that's been
done. Add another level of indirection to the create-kernel-packages
target to organize all of the kernel flavors under a single target that
is ordered before the create-dtb-packages target.

Note that we may later refine these targets after further pkgbase
review; this is simply a maybe-final stop-gap that's been tested to
fix a known problem.

MFC after: 37 seconds (pkgbase fix for 15.0 builds)
Reviewed and tested by: cperciva
Differential Revision: https://reviews.freebsd.org/D53017

show more ...

build: don't create duplicate bootstrap-tools targets

The general problem is that we might have a somewhat complicated
dependency tree depending on bootstrap version requirements. We could
document

build: don't create duplicate bootstrap-tools targets

The general problem is that we might have a somewhat complicated
dependency tree depending on bootstrap version requirements. We could
document when multiple bootstrap tools might have a shared dependency
and be careful to add them only once to the list, but that is a little
more fragile- particularly if we purge some bootstrap tools and need to
re-work the logic a little bit.

Just avoid redefining the build commands as we're iterating over the
list so that we can keep the actual requirements intact.

PR: 289997
Reported by: dhw, others
Reviewed by: imp
Fixes: 151bd3516b5 ("flua: support our flua modules in [...]")
Differential Revision: https://reviews.freebsd.org/D52904

show more ...

Makefile.inc1: Add back missing if

The .if defined(_MKSHOWCONFIG) covered an unusually large area, so it
should have not been removed in the last commit. I must have tested in
the wrong tree before

Makefile.inc1: Add back missing if

The .if defined(_MKSHOWCONFIG) covered an unusually large area, so it
should have not been removed in the last commit. I must have tested in
the wrong tree before pushing...

FixeS: 28b858f5059c
Sponsored by: Netflix

show more ...

Makefile.inc1: Remove svn support

We don't need this, and we don't use this. It's left over from the svn
days. We stopped supporting svn as a project entirely when 12.x went
EOL. And VCS_REVSION isn

Makefile.inc1: Remove svn support

We don't need this, and we don't use this. It's left over from the svn
days. We stopped supporting svn as a project entirely when 12.x went
EOL. And VCS_REVSION isn't in any current ucl file or anywhere else in
the tree.

Sponsored by: Netflix
Reviewed by : kevans, brd
Differential Revision: https://reviews.freebsd.org/D52912

show more ...

flua: support our flua modules in the bootstrap flua

This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
canno

flua: support our flua modules in the bootstrap flua

This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED. As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules. Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.

Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts. On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.

.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.

This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant. We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.

Reviewed by: bapt, emaste (both previous version)
Differential Revision: https://reviews.freebsd.org/D51890

show more ...