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:
parent
3bf06c2c6f
commit
f02d6f9f3c
|
|
@ -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
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue