trustfence-cst: use the same toolchain when building internal openssl and cst

An internal build of openssl is compiled as part of the cst build process,
which is later linked statically to the tool. When building the nativesdk
version of cst, openssl's internal "Configure" tool chooses Yocto's nativesdk
compiler for its compilation (x86_64-deysdk-linux-gcc). However, cst's Makefile
uses host tools by default, meaning it will compile its C files with the host's
gcc and link the final binary with the host's ld. This can lead to errors due
to the Yocto nativesdk compiler including symbols in the openssl libraries that
are unknown to the host's linker.

For example, when attempting to build nativesdk-trustfence-cst in Yocto 5.0 on
Ubuntu 2020.04, the following linker error appears multiple times:

undefined reference to `__isoc23_strtol'

Fix this by making sure cst uses the same toolchain as the one used when
building the internal openssl libraries (and ultimately, when the final binary
is linked together). This doesn't affect the native version of cst, which uses
the host's toolchain.

Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This commit is contained in:
Gabriel Valcazar 2024-10-28 13:55:08 +01:00
parent 3bf06c2c6f
commit f02d6f9f3c
1 changed files with 2 additions and 0 deletions

View File

@ -27,6 +27,8 @@ SRC_URI[openssl.sha256sum] = "8dee9b24bdb1dcbf0c3d1e9b02fb8f6bf22165e807f45adeb7
S = "${WORKDIR}/cst-${PV}" S = "${WORKDIR}/cst-${PV}"
EXTRA_OEMAKE = 'CC="${CC}" LD="${CC}" AR="${AR}" OBJCOPY="${OBJCOPY}"'
do_compile() { do_compile() {
cd code/cst cd code/cst
oe_runmake OPENSSL_PATH=${WORKDIR}/openssl-${OPENSSL1_VERSION} OSTYPE=linux64 openssl oe_runmake OPENSSL_PATH=${WORKDIR}/openssl-${OPENSSL1_VERSION} OSTYPE=linux64 openssl