Page MenuHomeFreeBSD

src.sys.obj.mk: Export OBJTOP like OBJROOT
AcceptedPublic

Authored by jrtc27 on Jul 2 2021, 12:38 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Feb 7, 6:38 PM
Unknown Object (File)
Fri, Jan 30, 4:11 PM
Unknown Object (File)
Dec 10 2025, 1:01 AM
Unknown Object (File)
Nov 28 2025, 12:37 PM
Unknown Object (File)
Nov 23 2025, 11:19 AM
Unknown Object (File)
Nov 22 2025, 11:14 AM
Unknown Object (File)
Nov 9 2025, 4:00 AM
Unknown Object (File)
Nov 6 2025, 5:30 AM
Subscribers

Details

Reviewers
bdrewery
imp
sjg
Summary

The default MAKEOBJDIR is based on OBJTOP not OBJROOT. Without this some
recursive makes for various targets compute an .OBJDIR under / and make
prints various warnings of the form:

make[5] warning: /lib: Permission denied.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 40226
Build 37115: arc lint + arc unit

Event Timeline

Solves it for me too. I'd add sjg as well

This revision is now accepted and ready to land.Jul 2 2021, 12:41 AM

More scrutiny for this would be good, these parts of the build system always risk being like a game of whack-a-mole...

share/mk/src.sys.obj.mk
99

This is dangerous depending on build mode.
In DIRDEPS build, we do not want to .export anything from level 0 (responsible only for build orchestration) that is not constant.

`.if ${.MAKE.LEVEL} > 0
.export OBJTOP
.endif`

would be safe. Does that work for your case?

share/mk/src.sys.obj.mk
99

This is all under .if ${MK_DIRDEPS_BUILD} == "no" (line 79). But yes it probably does; OBJROOT and SRCDIR get an .if ${.MAKE.LEVEL} == 0 already for free as all of their logic is guarded by that. I'll give it a test tomorrow.

I see that this review has kind of stalled.

I've just given a test to the change and I see a problem (maybe related to what @sjg warned about):

+ make installworld distrib-dirs installkernel -s -j6 '__MAKE_CONF=/usr/home/avg/devel/builds/rock/make.conf' 'SRCCONF=/usr/home/avg/devel/builds/rock/src.conf' 'KERNCONFDIR=/usr/home/avg/devel/builds/rock' 'KERNCONF=KERNEL' 'DESTDIR=/usr/obj/rock/image' 'DB_FROM_SRC=t' 'NO_ROOT=t'
make[1]: "/usr/devel/git/rock/Makefile.inc1" line 106: A build is required first.  You may have the wrong MAKEOBJDIRPREFIX set.

Seems like it could be related to this line:

.-include "${OBJTOP}/toolchain-metadata.mk"

The patch below, builds buildworld ok, avoids these warnings (due to OBJTOP being empty when evaluatinng MAKEOBJDIR which is set to ${.CURDIR:S,${SRCTOP},${OBJTOP},}

diff --git a/share/mk/src.sys.obj.mk b/share/mk/src.sys.obj.mk
index e4fe3fa9a2aa..67af0b833faa 100644
--- a/share/mk/src.sys.obj.mk
+++ b/share/mk/src.sys.obj.mk
@@ -88,18 +88,22 @@ SB_OBJROOT:= ${OBJROOT}
 # in the source tree.
 .if ${MK_UNIFIED_OBJDIR} == "yes" && ${SRCTOP} != ${OBJROOT:tA}
 .if defined(TARGET) && defined(TARGET_ARCH)
-OBJTOP:=       ${OBJROOT}${TARGET}.${TARGET_ARCH}
+OBJTOP:=       ${OBJROOT}$${TARGET}.$${TARGET_ARCH}
 .elif defined(TARGET) && ${.CURDIR} == ${SRCTOP}
 # Not enough information, just use basic OBJDIR.  This can happen with some
 # 'make universe' targets or if TARGET is not being used as expected.
 OBJTOP:=       ${OBJROOT:H}
 .else
-OBJTOP:=       ${OBJROOT}${MACHINE}.${MACHINE_ARCH}
+OBJTOP:=       ${OBJROOT}$${MACHINE}.$${MACHINE_ARCH}
 .endif
 .else
 # TARGET.TARGET_ARCH handled in OBJROOT already.
 OBJTOP:=       ${OBJROOT:H}
 .endif # ${MK_UNIFIED_OBJDIR} == "yes"
+# export but do not track
+.export-env OBJTOP
+# resolve if needed
+OBJTOP:= ${OBJTOP}
 .endif # empty(OBJTOP)
 
 # Fixup OBJROOT/OBJTOP if using MAKEOBJDIRPREFIX.
share/mk/src.sys.obj.mk
99

I take it back. One cannot have MAKEOBJDIR depend on OBJTOP and *not* have OBJTOP exported as you have it. It may be safer to use .export-env though that might only matter if doing universe - you might want to export OBJTOP=${OBJROOT}$${MACHINE}.$${MACHINE_ARCH} in which case .export-env would be what you want. Much the same as is done for MAKEOBJDIR

FWIW this simple .export OBJTOP works ok for buildworld but not for targets like universe where multiple arches try to use the same OBJTOP which quickly ends in tears.
The more elaborate patch in https://reviews.freebsd.org/D54819 blows up in buildworld due to being incompatible with assumptions made by all the *compat* bits, but once that compat stuff is fixed, probably has a hope of working for universe too.