On Sun, Jun 25, 2023 at 1:53 PM Martin Jansa <[email protected]> wrote:
>
> On Mon, Jun 19, 2023 at 8:26 PM Beniamin Sandu <[email protected]>
> wrote:
>>
>> Version 3.4.0 adds a lot of improvements and fixes (a notable one
>> being initial support for PKCS7 CMS), but since this is a pretty
>> big jump, let's keep both versions for a while, so the v2.x users
>> can upgrade to 3.x in a timely manner if needed.
>>
>> Signed-off-by: Beniamin Sandu <[email protected]>
>> ---
>> .../mbedtls/mbedtls_3.4.0.bb | 85 +++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>> create mode 100644
>> meta-networking/recipes-connectivity/mbedtls/mbedtls_3.4.0.bb
>>
>> diff --git a/meta-networking/recipes-connectivity/mbedtls/mbedtls_3.4.0.bb
>> b/meta-networking/recipes-connectivity/mbedtls/mbedtls_3.4.0.bb
>> new file mode 100644
>> index 000000000..ebc6ba573
>> --- /dev/null
>> +++ b/meta-networking/recipes-connectivity/mbedtls/mbedtls_3.4.0.bb
>
>
> ....
>
>> +# Needs crypto instructions on aarch64
>> +TUNE_CCARGS_MARCH_OPTS:append:aarch64 =
>> "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '', '+crypto', d)}"
>
>
> This assumes too much about TUNE_CCARGS_MARCH_OPTS structure and in some
> multilib builds I'm seeing:
>
> # $TUNE_CCARGS_MARCH_OPTS [4 operations]
> # set oe-core/meta/conf/machine/include/arm/arch-arm.inc:19
> # [_defaultval] ""
> # postdot oe-core/meta/conf/machine/include/arm/feature-arm-neon.inc:26
> # "${@bb.utils.contains('TUNE_FEATURES', [ 'vfpv3d16', 'vfpv5spd16' ],
> '+fp', '', d)}"
> # postdot oe-core/meta/conf/machine/include/arm/feature-arm-simd.inc:5
> # "${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '', d)}"
> # :append[aarch64]
> meta-oe/meta-networking/recipes-connectivity/mbedtls/mbedtls_3.4.0.bb:45
> # "${@bb.utils.contains('TUNE_FEATURES', 'crypto', '', '+crypto', d)}"
> # pre-expansion value:
> # "${@bb.utils.contains('TUNE_FEATURES', [ 'vfpv3d16', 'vfpv5spd16' ],
> '+fp', '', d)}${@bb.utils.contains('TUNE_FEATURES', 'simd', '+simd', '',
> d)}${@bb.utils.contains('TUNE_FEATURES', 'crypto', '', '+crypto', d)}"
> TUNE_CCARGS_MARCH_OPTS="+crypto"
>
> And empty TUNE_CCARGS_MARCH, because TUNE_FEATURES has only aarch64
>
> # $TUNE_CCARGS_MARCH [4 operations]
> # postdot oe-core/meta/conf/machine/include/arm/arch-armv7a.inc:6
> # "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', ' -march=armv7-a', '',
> d)}"
> # postdot oe-core/meta/conf/machine/include/arm/arch-armv6.inc:5
> # "${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' -march=armv6', '',
> d)}"
> # postdot oe-core/meta/conf/machine/include/arm/arch-armv5.inc:5
> # "${@bb.utils.contains('TUNE_FEATURES', 'armv5', '
> -march=armv5t${ARMPKGSFX_DSP}', '', d)}"
> # postdot oe-core/meta/conf/machine/include/arm/arch-armv4.inc:5
> # "${@bb.utils.contains('TUNE_FEATURES', 'armv4', '
> -march=armv4${ARMPKGSFX_THUMB}', '', d)}"
> # pre-expansion value:
> # "${@bb.utils.contains('TUNE_FEATURES', 'armv7a', ' -march=armv7-a', '',
> d)}${@bb.utils.contains('TUNE_FEATURES', 'armv6', ' -march=armv6', '',
> d)}${@bb.utils.contains('TUNE_FEATURES', 'armv5', '
> -march=armv5t${ARMPKGSFX_DSP}', '', d)}${@bb.utils.contains('TUNE_FEATURES',
> 'armv4', ' -march=armv4${ARMPKGSFX_THUMB}', '', d)}"
> TUNE_CCARGS_MARCH=""
>
> causing do_configure failure:
>
> aarch64-oe-linux-gcc: warning: +crypto: linker input file unused because
> linking not done
> aarch64-oe-linux-gcc: error: +crypto: linker input file not found: No such
> file or directory
> ninja: build stopped: subcommand failed.
As I understand, you are building a lib64 multilib variant with a pure
aarch64 tune (no core specifications or optimizations whatsoever)?
I have tested with a bunch of different machines and tuning variations
on my side, but I never encountered a build in the real world with
arm64 instructions enabled and nothing else, so did not think trying
out this one would be useful.
Building with crypto instructions on arm64 machines was the path with
the least resistance in getting rid of compilation errors because of
target specific option mismatches, but I will look if there is better
way to handle this when I get the chance.
>
>> +
>> +# For now the only way to enable PSA is to explicitly pass a -D via CFLAGS
>> +CFLAGS:append = "${@bb.utils.contains('PACKAGECONFIG', 'psa', '
>> -DMBEDTLS_USE_PSA_CRYPTO', '', d)}"
>> +
>> +PROVIDES += "polarssl"
>> +RPROVIDES:${PN} = "polarssl"
>> +
>> +PACKAGES =+ "${PN}-programs"
>> +FILES:${PN}-programs = "${bindir}/"
>> +
>> +ALTERNATIVE:${PN}-programs = "hello"
>> +ALTERNATIVE_LINK_NAME[hello] = "${bindir}/hello"
>> +
>> +BBCLASSEXTEND = "native nativesdk"
>> +
>> +CVE_PRODUCT = "mbed_tls"
>> +
>> +# Fix merged upstream https://github.com/Mbed-TLS/mbedtls/pull/5310
>> +CVE_CHECK_IGNORE += "CVE-2021-43666"
>> +# Fix merged upstream
>> https://github.com/Mbed-TLS/mbedtls/commit/9a4a9c66a48edfe9ece03c7e4a53310adf73a86c
>> +CVE_CHECK_IGNORE += "CVE-2021-45451"
>> +
>> +# Strip host paths from autogenerated test files
>> +do_compile:append() {
>> + sed -i 's+${S}/++g' ${B}/tests/*.c 2>/dev/null || :
>> + sed -i 's+${B}/++g' ${B}/tests/*.c 2>/dev/null || :
>> +}
>> +
>> +# Export source files/headers needed by Arm Trusted Firmware
>> +sysroot_stage_all:append() {
>> + sysroot_stage_dir "${S}/library"
>> "${SYSROOT_DESTDIR}/usr/share/mbedtls-source/library"
>> + sysroot_stage_dir "${S}/include"
>> "${SYSROOT_DESTDIR}/usr/share/mbedtls-source/include"
>> +}
>> +
>> +do_install_ptest () {
>> + install -d ${D}${PTEST_PATH}/tests
>> + cp -f ${B}/tests/test_suite_* ${D}${PTEST_PATH}/tests/
>> + find ${D}${PTEST_PATH}/tests/ -type f -name "*.c" -delete
>> + cp -fR ${S}/tests/data_files ${D}${PTEST_PATH}/tests/
>> +}
>> --
>> 2.25.1
>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#103561):
https://lists.openembedded.org/g/openembedded-devel/message/103561
Mute This Topic: https://lists.openembedded.org/mt/99629175/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
