2019-10-15 21:08:49 +00:00
|
|
|
|
|
|
|
.if !targets(__<${_this:T}>__)
|
|
|
|
__<${_this:T}>__:
|
|
|
|
|
2023-07-27 04:10:43 +00:00
|
|
|
.include <bsd.compat.pre.mk>
|
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)
|
2020-03-07 03:58:58 +00:00
|
|
|
COMPAT_ARCH?= ${TARGET_ARCH}
|
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 _LIBCOMPAT in ${_ALL_LIBCOMPATS}
|
|
|
|
LIB${_LIBCOMPAT}CPUTYPE?= ${CPUTYPE_${_LIBCOMPAT}}
|
|
|
|
.endfor
|
2019-11-07 22:58:10 +00:00
|
|
|
.if (defined(WANT_COMPILER_TYPE) && ${WANT_COMPILER_TYPE} == gcc) || \
|
|
|
|
(defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
|
|
|
|
COMPAT_COMPILER_TYPE= gcc
|
|
|
|
.else
|
|
|
|
COMPAT_COMPILER_TYPE= clang
|
|
|
|
.endif
|
2019-10-31 20:37:19 +00:00
|
|
|
.else
|
|
|
|
COMPAT_ARCH= ${MACHINE_ARCH}
|
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 _LIBCOMPAT in ${_ALL_LIBCOMPATS}
|
|
|
|
LIB${_LIBCOMPAT}CPUTYPE= ${CPUTYPE}
|
|
|
|
.endfor
|
2019-11-07 22:58:10 +00:00
|
|
|
.include <bsd.compiler.mk>
|
|
|
|
COMPAT_COMPILER_TYPE=${COMPILER_TYPE}
|
2019-10-31 20:37:19 +00:00
|
|
|
.endif
|
|
|
|
|
2019-10-15 21:08:49 +00:00
|
|
|
# -------------------------------------------------------------------
|
|
|
|
# 32 bit world
|
2019-10-31 20:37:19 +00:00
|
|
|
.if ${COMPAT_ARCH} == "amd64"
|
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
|
|
|
HAS_COMPAT+= 32
|
|
|
|
.if empty(LIB32CPUTYPE)
|
2019-10-15 21:08:49 +00:00
|
|
|
LIB32CPUFLAGS= -march=i686 -mmmx -msse -msse2
|
|
|
|
.else
|
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
|
|
|
LIB32CPUFLAGS= -march=${LIB32CPUTYPE}
|
2019-10-15 21:08:49 +00:00
|
|
|
.endif
|
2019-11-07 22:58:10 +00:00
|
|
|
.if ${COMPAT_COMPILER_TYPE} == gcc
|
2019-10-15 21:08:49 +00:00
|
|
|
.else
|
2022-05-03 11:09:38 +00:00
|
|
|
LIB32CPUFLAGS+= -target x86_64-unknown-freebsd${OS_REVISION}
|
2019-10-15 21:08:49 +00:00
|
|
|
.endif
|
|
|
|
LIB32CPUFLAGS+= -m32
|
2019-11-07 22:58:10 +00:00
|
|
|
LIB32_MACHINE= i386
|
|
|
|
LIB32_MACHINE_ARCH= i386
|
|
|
|
LIB32WMAKEENV= MACHINE_CPU="i686 mmx sse sse2"
|
2019-10-15 21:08:49 +00:00
|
|
|
LIB32WMAKEFLAGS= \
|
2020-08-17 17:17:33 +00:00
|
|
|
LD="${XLD} -m elf_i386_fbsd"
|
2019-10-15 21:08:49 +00:00
|
|
|
|
2019-10-31 20:37:19 +00:00
|
|
|
.elif ${COMPAT_ARCH} == "powerpc64"
|
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
|
|
|
HAS_COMPAT+= 32
|
|
|
|
.if empty(LIB32CPUTYPE)
|
2019-10-15 21:08:49 +00:00
|
|
|
LIB32CPUFLAGS= -mcpu=powerpc
|
|
|
|
.else
|
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
|
|
|
LIB32CPUFLAGS= -mcpu=${LIB32CPUTYPE}
|
2019-10-15 21:08:49 +00:00
|
|
|
.endif
|
2019-12-24 16:03:33 +00:00
|
|
|
|
|
|
|
.if ${COMPAT_COMPILER_TYPE} == "gcc"
|
2019-10-15 21:08:49 +00:00
|
|
|
LIB32CPUFLAGS+= -m32
|
2019-12-24 16:03:33 +00:00
|
|
|
.else
|
2022-05-03 11:09:38 +00:00
|
|
|
LIB32CPUFLAGS+= -target powerpc-unknown-freebsd${OS_REVISION}
|
2019-12-24 16:03:33 +00:00
|
|
|
.endif
|
|
|
|
|
2019-11-07 22:58:10 +00:00
|
|
|
LIB32_MACHINE= powerpc
|
|
|
|
LIB32_MACHINE_ARCH= powerpc
|
2020-03-27 18:20:36 +00:00
|
|
|
LIB32WMAKEFLAGS= \
|
|
|
|
LD="${XLD} -m elf32ppc_fbsd"
|
2023-07-25 23:59:52 +00:00
|
|
|
|
|
|
|
.elif ${COMPAT_ARCH} == "aarch64"
|
|
|
|
HAS_COMPAT+= 32
|
|
|
|
.if empty(LIB32CPUTYPE)
|
|
|
|
LIB32CPUFLAGS= -march=armv7
|
|
|
|
.else
|
|
|
|
LIB32CPUFLAGS= -mcpu=${LIB32CPUTYPE}
|
|
|
|
.endif
|
|
|
|
|
|
|
|
LIB32CPUFLAGS+= -m32
|
|
|
|
.if ${COMPAT_COMPILER_TYPE} == "gcc"
|
|
|
|
.else
|
|
|
|
LIB32CPUFLAGS+= -target armv7-unknown-freebsd${OS_REVISION}-gnueabihf
|
|
|
|
.endif
|
|
|
|
|
|
|
|
LIB32_MACHINE= arm
|
|
|
|
LIB32_MACHINE_ARCH= armv7
|
|
|
|
LIB32WMAKEFLAGS= \
|
|
|
|
LD="${XLD} -m armelf_fbsd"
|
2019-10-15 21:08:49 +00:00
|
|
|
.endif
|
|
|
|
|
|
|
|
LIB32WMAKEFLAGS+= NM="${XNM}"
|
|
|
|
LIB32WMAKEFLAGS+= OBJCOPY="${XOBJCOPY}"
|
|
|
|
|
|
|
|
LIB32DTRACE= ${DTRACE} -32
|
2022-10-05 16:26:30 +00:00
|
|
|
LIB32_MACHINE_ABI= ${MACHINE_ABI:N*64} long32 ptr32
|
|
|
|
.if ${COMPAT_ARCH} == "amd64"
|
|
|
|
LIB32_MACHINE_ABI+= time32
|
|
|
|
.else
|
|
|
|
LIB32_MACHINE_ABI+= time64
|
|
|
|
.endif
|
2019-10-15 21:08:49 +00:00
|
|
|
|
2019-10-15 21:27:06 +00:00
|
|
|
# -------------------------------------------------------------------
|
|
|
|
# In the program linking case, select LIBCOMPAT
|
|
|
|
.if defined(NEED_COMPAT)
|
|
|
|
.ifndef HAS_COMPAT
|
2022-02-04 23:57:28 +00:00
|
|
|
.warning NEED_COMPAT defined, but no LIBCOMPAT is available (COMPAT_ARCH == ${COMPAT_ARCH})
|
2019-10-15 21:27:06 +00:00
|
|
|
.elif !${HAS_COMPAT:M${NEED_COMPAT}} && ${NEED_COMPAT} != "any"
|
2022-02-04 23:57:28 +00:00
|
|
|
.error NEED_COMPAT (${NEED_COMPAT}) defined, but not in HAS_COMPAT (${HAS_COMPAT})
|
2019-10-15 21:27:06 +00:00
|
|
|
.elif ${NEED_COMPAT} == "any"
|
|
|
|
.endif
|
|
|
|
.ifdef WANT_COMPAT
|
|
|
|
.error Both WANT_COMPAT and NEED_COMPAT defined
|
|
|
|
.endif
|
|
|
|
WANT_COMPAT:= ${NEED_COMPAT}
|
|
|
|
.endif
|
|
|
|
|
|
|
|
.if defined(HAS_COMPAT) && defined(WANT_COMPAT)
|
|
|
|
.if ${WANT_COMPAT} == "any"
|
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
|
|
|
USE_COMPAT:= ${HAS_COMPAT:[1]}
|
2019-10-15 21:27:06 +00:00
|
|
|
.else
|
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
|
|
|
USE_COMPAT:= ${WANT_COMPAT}
|
2019-10-15 21:27:06 +00:00
|
|
|
.endif
|
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
|
|
|
|
|
|
|
_LIBCOMPATS= ${USE_COMPAT}
|
2019-10-15 21:27:06 +00:00
|
|
|
.endif
|
|
|
|
|
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
|
|
|
libcompats= ${_LIBCOMPATS:tl}
|
|
|
|
|
2019-10-15 21:08:49 +00:00
|
|
|
# -------------------------------------------------------------------
|
|
|
|
# Generic code for each type.
|
|
|
|
# Set defaults based on type.
|
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 _LIBCOMPAT _libcompat in ${_LIBCOMPATS:@v@${v} ${v:tl}@}
|
2022-07-01 07:33:16 +00:00
|
|
|
WORLDTMP?= ${SYSROOT}
|
|
|
|
|
2019-10-15 21:08:49 +00:00
|
|
|
# Shared flags
|
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}_OBJTOP?= ${OBJTOP}/obj-lib${_libcompat}
|
2019-10-15 21:08:49 +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
|
|
|
LIB${_LIBCOMPAT}CFLAGS+= ${LIB${_LIBCOMPAT}CPUFLAGS} \
|
bsd.compat.mk: Provide new CPP and sub-make variables
Currently the only way to detect for a libcompat build is to consult
whether COMPAT_32BIT is defined (or equivalent, for downstreams with
other libcompats or past releases with libsoft as COMPAT_SOFTFP). There
are two issues with this:
1. COMPAT_32BIT is a new naming scheme that doesn't match the libcompat
name, which is unnecessary deviation.
2. When multiple libcompats exist, everywhere that needs to detect a
libcompat must check each variable in turn, despite the fact that it
normally just wants to know if this is a libcompat build and perhaps
what ${LIBCOMPAT} and/or ${libcompat} are for it.
As a result, far too many places in the tree need to know about the set
of possible libcompats.
Instead, introduce two new CPP and sub-make variables, COMPAT_LIBCOMPAT
and COMPAT_libcompat, which give the values for ${LIBCOMPAT} and
${libcompat} respectively, so that uses can be made parameterised. For
when code really does need to know the specific libcompat, Makefiles can
perform a string comparison, but the C preprocessor cannot, so introduce
an additional CPP-only COMPAT_LIB${LIBCOMPAT} which is intended to
replace the inconsistently-named COMPAT_32BIT (which will be removed in
future). Uses of this new variable should still be kept to a minimum,
however, given the code duplication needed for new libcompats.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40922
2023-07-09 17:47:42 +00:00
|
|
|
-DCOMPAT_LIBCOMPAT=\"${_LIBCOMPAT}\" \
|
|
|
|
-DCOMPAT_libcompat=\"${_libcompat}\" \
|
|
|
|
-DCOMPAT_LIB${_LIBCOMPAT} \
|
2023-07-07 19:17:19 +00:00
|
|
|
--sysroot=${WORLDTMP} \
|
|
|
|
${BFLAGS}
|
2019-10-15 21:08:49 +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
|
|
|
LIB${_LIBCOMPAT}LDFLAGS+= -L${WORLDTMP}/usr/lib${_libcompat}
|
2020-08-17 17:17:33 +00:00
|
|
|
|
bsd.compat.mk: Provide new CPP and sub-make variables
Currently the only way to detect for a libcompat build is to consult
whether COMPAT_32BIT is defined (or equivalent, for downstreams with
other libcompats or past releases with libsoft as COMPAT_SOFTFP). There
are two issues with this:
1. COMPAT_32BIT is a new naming scheme that doesn't match the libcompat
name, which is unnecessary deviation.
2. When multiple libcompats exist, everywhere that needs to detect a
libcompat must check each variable in turn, despite the fact that it
normally just wants to know if this is a libcompat build and perhaps
what ${LIBCOMPAT} and/or ${libcompat} are for it.
As a result, far too many places in the tree need to know about the set
of possible libcompats.
Instead, introduce two new CPP and sub-make variables, COMPAT_LIBCOMPAT
and COMPAT_libcompat, which give the values for ${LIBCOMPAT} and
${libcompat} respectively, so that uses can be made parameterised. For
when code really does need to know the specific libcompat, Makefiles can
perform a string comparison, but the C preprocessor cannot, so introduce
an additional CPP-only COMPAT_LIB${LIBCOMPAT} which is intended to
replace the inconsistently-named COMPAT_32BIT (which will be removed in
future). Uses of this new variable should still be kept to a minimum,
however, given the code duplication needed for new libcompats.
Reviewed by: emaste, brooks, jhb
Differential Revision: https://reviews.freebsd.org/D40922
2023-07-09 17:47:42 +00:00
|
|
|
LIB${_LIBCOMPAT}WMAKEFLAGS+= COMPAT_LIBCOMPAT=${_LIBCOMPAT} \
|
|
|
|
COMPAT_libcompat=${_libcompat}
|
|
|
|
|
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+= MACHINE=${LIB${_LIBCOMPAT}_MACHINE}
|
|
|
|
LIB${_LIBCOMPAT}WMAKEENV+= MACHINE_ARCH=${LIB${_LIBCOMPAT}_MACHINE_ARCH}
|
2019-11-07 22:58:10 +00:00
|
|
|
|
2022-01-07 05:34:15 +00:00
|
|
|
# -B is needed to find /usr/lib32/crti.o for gcc.
|
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}CFLAGS+= -B${WORLDTMP}/usr/lib${_libcompat}
|
|
|
|
.endfor
|
|
|
|
|
|
|
|
.if defined(USE_COMPAT)
|
|
|
|
libcompat= ${USE_COMPAT:tl}
|
|
|
|
|
|
|
|
_LIBCOMPAT_MAKEVARS= _OBJTOP TMP CPUFLAGS CFLAGS CXXFLAGS LDFLAGS \
|
|
|
|
_MACHINE _MACHINE_ARCH _MACHINE_ABI \
|
|
|
|
WMAKEENV WMAKEFLAGS WMAKE WORLDTMP
|
|
|
|
.for _var in ${_LIBCOMPAT_MAKEVARS}
|
|
|
|
.if !empty(LIB${USE_COMPAT}${_var})
|
|
|
|
LIBCOMPAT${_var}?= ${LIB${USE_COMPAT}${_var}}
|
|
|
|
.endif
|
|
|
|
.endfor
|
2019-10-15 21:08:49 +00:00
|
|
|
|
2019-10-15 21:27:06 +00:00
|
|
|
LIBDIR_BASE:= /usr/lib${libcompat}
|
2022-08-11 22:17:52 +00:00
|
|
|
LIBDATADIR:= /usr/lib${libcompat}
|
2019-10-15 21:27:06 +00:00
|
|
|
_LIB_OBJTOP= ${LIBCOMPAT_OBJTOP}
|
|
|
|
CFLAGS+= ${LIBCOMPATCFLAGS}
|
2019-11-07 22:58:10 +00:00
|
|
|
LDFLAGS+= ${CFLAGS} ${LIBCOMPATLDFLAGS}
|
|
|
|
MACHINE= ${LIBCOMPAT_MACHINE}
|
|
|
|
MACHINE_ARCH= ${LIBCOMPAT_MACHINE_ARCH}
|
2019-10-15 21:27:06 +00:00
|
|
|
.endif
|
|
|
|
|
2019-10-15 21:08:49 +00:00
|
|
|
.endif
|