2016-03-11 23:56:33 +00:00
|
|
|
|
|
|
|
|
.if !targets(__<${_this:T}>__)
|
|
|
|
|
__<${_this:T}>__:
|
|
|
|
|
|
|
|
|
|
# Makefile for the compatibility libraries.
|
2023-07-25 23:59:52 +00:00
|
|
|
# - 32-bit compat libraries on some 64-bit architectures
|
2016-03-11 23:56:33 +00:00
|
|
|
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
.if defined(_LIBCOMPATS)
|
|
|
|
|
|
2019-10-15 21:08:49 +00:00
|
|
|
.include <bsd.compat.mk>
|
2016-06-15 23:58:03 +00:00
|
|
|
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
.for libcompatidx _LIBCOMPAT libcompat in ${_LIBCOMPATS:range:@i@${i} ${_LIBCOMPATS:[$i]} ${libcompats:[$i]}@}
|
|
|
|
|
|
2016-03-11 23:56:33 +00:00
|
|
|
# Yes, the flags are redundant.
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
LIB${_LIBCOMPAT}WMAKEENV+= \
|
2020-10-08 17:30:05 +00:00
|
|
|
INSTALL="${INSTALL_CMD} -U" \
|
2016-03-11 23:56:33 +00:00
|
|
|
PATH=${TMPPATH} \
|
2022-07-01 07:33:16 +00:00
|
|
|
SYSROOT=${WORLDTMP} \
|
2016-03-11 23:56:33 +00:00
|
|
|
LIBDIR=/usr/lib${libcompat} \
|
|
|
|
|
SHLIBDIR=/usr/lib${libcompat} \
|
2022-08-11 22:17:52 +00:00
|
|
|
LIBDATADIR=/usr/lib${libcompat} \
|
2023-08-10 23:48:01 +00:00
|
|
|
DTRACE="${LIB${_LIBCOMPAT}DTRACE:U${DTRACE}}"
|
2016-04-14 21:06:10 +00:00
|
|
|
.if ${MK_META_MODE} != "no"
|
|
|
|
|
# Don't rebuild build-tools targets during normal build.
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
LIB${_LIBCOMPAT}WMAKEENV+= BUILD_TOOLS_META=.NOMETA
|
2016-04-14 21:06:10 +00:00
|
|
|
.endif
|
Makefile.libcompat: Make quoting for CC/CXX/CPP more future-proof
bmake's :Q is for quoting outside of double quotes, but here is inside
double quotes, and as a result it ends up quoting characters that don't
have a special meaning inside double quotes. On the surface this would
seem harmless, but POSIX sh has a strange behaviour (differing from
outside double quotes) that, inside double quotes, a backslash before a
character that never has a special meaning inside double quotes is
passed through. As a result, should LIB${_LIBCOMPAT}CFLAGS contain
something like -DFOO\(x\)=x, we would form "... -DFOO\\\(x\\\)=x ...",
which would be parsed as -DFOO\\(x\\)=x, since the parentheses are never
special inside double quotes (but the backslash itself is), not the
original -DFOO\(x\)=x as intended.
Instead, construct the whole string as a bmake expression and use :Q on
that, without the manual double quotes around everything. Note that the
:L modifier lets you treat an expression like a variable expansion and
apply modifiers to it, i.e. ${expr:L:...} is the same as tmp=expr
${tmp:...} (in essence, ignoring possible differences due to deferred
substitution).
Improves: 537f945fc89f ("Makefile.libcompat: Quote CFLAGS and CXXFLAGS for sub-make")
2023-07-14 04:34:03 +00:00
|
|
|
LIB${_LIBCOMPAT}WMAKEFLAGS+= CC=${${XCC} ${LIB${_LIBCOMPAT}CFLAGS}:L:Q} \
|
|
|
|
|
CXX=${${XCXX} ${LIB${_LIBCOMPAT}CXXFLAGS} ${LIB${_LIBCOMPAT}CFLAGS}:L:Q} \
|
|
|
|
|
CPP=${${XCPP} ${LIB${_LIBCOMPAT}CFLAGS}:L:Q} \
|
2022-07-01 07:33:16 +00:00
|
|
|
DESTDIR=${WORLDTMP} \
|
2016-03-11 23:56:33 +00:00
|
|
|
-DNO_CPU_CFLAGS \
|
2022-02-02 21:34:29 +00:00
|
|
|
MK_BOOT=no \
|
2016-03-11 23:56:33 +00:00
|
|
|
MK_CTF=no \
|
2022-02-02 21:34:29 +00:00
|
|
|
MK_TESTS=no
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
LIB${_LIBCOMPAT}WMAKE+= ${TIME_ENV} ${LIB${_LIBCOMPAT}WMAKEENV} ${MAKE} \
|
|
|
|
|
${LIB${_LIBCOMPAT}WMAKEFLAGS} \
|
|
|
|
|
OBJTOP=${LIB${_LIBCOMPAT}_OBJTOP} \
|
2017-11-05 00:11:47 +00:00
|
|
|
OBJROOT='$${OBJTOP}/' \
|
2023-08-01 21:01:57 +00:00
|
|
|
UNIVERSE_TOOLCHAIN_PATH=${UNIVERSE_TOOLCHAIN_PATH} \
|
2017-11-05 00:11:51 +00:00
|
|
|
MAKEOBJDIRPREFIX= \
|
Makefile.libcompat: Be consistent about not installing includes
Currently we only pass MK_INCLUDES=no for distribute and install, since
it's only in LIB${_LIBCOMPAT}IMAKE, which means that we enable includes
during libraries and thus install includes into worldtmp, despite it
being shared these days across native and libcompats. This also means
we're at risk of having headers needed for building against a libcompat
that don't get installed to the system, but do end up being installed to
worldtmp. In particular, lib/msun has different fenv.h for aarch64 and
arm, so aarch64 will need arm's copy when it grows lib32 support, and
this would be installed to worldtmp, but not to the system, meaning any
programs that use fenv.h wouldn't be able to be built.
Instead, be consistent, and don't install includes at all during any of
the libcompat phases, so that we can detect these issues and ensure any
needed headers are installed for both worldtmp and the system.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D41030
2023-07-14 01:36:04 +00:00
|
|
|
MK_INCLUDES=no \
|
2016-03-11 23:56:33 +00:00
|
|
|
MK_MAN=no MK_HTML=no
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
LIB${_LIBCOMPAT}IMAKE+= ${LIB${_LIBCOMPAT}WMAKE:NINSTALL=*:NDESTDIR=*} \
|
2018-08-03 18:52:51 +00:00
|
|
|
${IMAKE_INSTALL} \
|
2016-03-25 19:12:13 +00:00
|
|
|
-DLIBRARIES_ONLY
|
2016-03-11 23:56:33 +00:00
|
|
|
|
|
|
|
|
# Shared logic
|
|
|
|
|
build${libcompat}: .PHONY
|
|
|
|
|
@echo
|
|
|
|
|
@echo "--------------------------------------------------------------"
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
@echo ">>> stage 4.3.${libcompatidx}: building lib${libcompat} shim libraries"
|
2016-03-11 23:56:33 +00:00
|
|
|
@echo "--------------------------------------------------------------"
|
2018-06-29 21:15:26 +00:00
|
|
|
${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
|
2022-07-01 07:33:16 +00:00
|
|
|
-p ${WORLDTMP}/usr >/dev/null
|
2016-03-11 23:56:33 +00:00
|
|
|
.if ${MK_DEBUG_FILES} != "no"
|
2018-06-29 21:15:26 +00:00
|
|
|
${WORLDTMP_MTREE} -f ${.CURDIR}/etc/mtree/BSD.lib${libcompat}.dist \
|
2022-07-01 07:33:16 +00:00
|
|
|
-p ${WORLDTMP}/usr/lib/debug/usr >/dev/null
|
2016-03-11 23:56:33 +00:00
|
|
|
.endif
|
2023-06-27 23:10:30 +00:00
|
|
|
${_+_}cd ${.CURDIR}; \
|
2016-03-11 23:56:33 +00:00
|
|
|
WORLDTMP=${WORLDTMP} \
|
|
|
|
|
MAKEFLAGS="-m ${.CURDIR}/tools/build/mk ${.MAKEFLAGS}" \
|
2023-06-27 23:10:30 +00:00
|
|
|
${MAKE} -f Makefile.inc1 \
|
|
|
|
|
DESTDIR= \
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
OBJTOP=${LIB${_LIBCOMPAT}_OBJTOP} \
|
2017-11-02 18:08:36 +00:00
|
|
|
OBJROOT='$${OBJTOP}/' \
|
2023-08-22 04:00:45 +00:00
|
|
|
UNIVERSE_TOOLCHAIN_PATH=${UNIVERSE_TOOLCHAIN_PATH} \
|
2017-11-05 00:11:51 +00:00
|
|
|
MAKEOBJDIRPREFIX= \
|
2021-08-04 18:17:34 +00:00
|
|
|
-DNO_LINT \
|
|
|
|
|
-DNO_CPU_CFLAGS \
|
|
|
|
|
MK_ASAN=no \
|
|
|
|
|
MK_CTF=no \
|
|
|
|
|
MK_RETPOLINE=no \
|
2021-08-04 18:20:50 +00:00
|
|
|
MK_SSP=no \
|
2021-08-04 18:17:34 +00:00
|
|
|
MK_UBSAN=no \
|
|
|
|
|
MK_WERROR=no \
|
2023-06-27 23:10:30 +00:00
|
|
|
_lc_build-tools
|
2016-03-11 23:56:33 +00:00
|
|
|
${_+_}cd ${.CURDIR}; \
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
${LIB${_LIBCOMPAT}WMAKE} -f Makefile.inc1 -DNO_FSCHG libraries
|
2016-03-11 23:56:33 +00:00
|
|
|
|
|
|
|
|
distribute${libcompat} install${libcompat}: .PHONY
|
2023-06-27 23:10:30 +00:00
|
|
|
${_+_}cd ${.CURDIR}; \
|
Generalise libcompat to be a list rather than a single option
Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.
For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.
Reviewed by: brooks, jhb, imp
Differential Revision: https://reviews.freebsd.org/D40571
2023-06-27 23:10:49 +00:00
|
|
|
${LIB${_LIBCOMPAT}IMAKE} -f Makefile.inc1 _lc_${.TARGET:S/${libcompat}$//}
|
|
|
|
|
|
|
|
|
|
.endfor # libcompatidx _LIBCOMPAT libcompat
|
|
|
|
|
|
|
|
|
|
.endif # defined(_LIBCOMPATS)
|
2023-06-27 23:10:30 +00:00
|
|
|
|
|
|
|
|
# These depend on MK_*, which could vary between the native and compat
|
|
|
|
|
# architectures. Thus targets using them are run within a compat sub-make
|
|
|
|
|
# rather than the native make environment.
|
|
|
|
|
|
|
|
|
|
_LC_LIBDIRS.yes= lib
|
|
|
|
|
_LC_LIBDIRS.yes+= gnu/lib
|
|
|
|
|
_LC_LIBDIRS.${MK_CDDL:tl}+= cddl/lib
|
|
|
|
|
_LC_LIBDIRS.${MK_CRYPT:tl}+= secure/lib
|
|
|
|
|
_LC_LIBDIRS.${MK_KERBEROS:tl}+= kerberos5/lib
|
|
|
|
|
|
|
|
|
|
.if ${MK_FILE} != "no"
|
|
|
|
|
_libmagic= lib/libmagic
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_PMC} != "no"
|
|
|
|
|
_jevents= lib/libpmc/pmu-events
|
|
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
_lc_build-tools:
|
|
|
|
|
.for _dir in lib/ncurses/tinfo ${_libmagic} ${_jevents}
|
|
|
|
|
.for _t in ${_obj} build-tools
|
|
|
|
|
${_+_}cd ${.CURDIR}/${_dir}; ${MAKE} DIRPRFX=${_dir}/ ${_t}
|
|
|
|
|
.endfor
|
|
|
|
|
.endfor
|
|
|
|
|
|
|
|
|
|
_lc_distribute _lc_install:
|
2016-03-11 23:56:33 +00:00
|
|
|
.for _dir in ${_LC_LIBDIRS.yes}
|
2023-06-27 23:10:30 +00:00
|
|
|
${_+_}cd ${.CURDIR}/${_dir}; ${MAKE} ${.TARGET:S/^_lc_//}
|
2016-03-11 23:56:33 +00:00
|
|
|
.endfor
|
|
|
|
|
|
2019-11-07 22:58:10 +00:00
|
|
|
.endif # !targets(__<${_this:T}>__)
|