Re: [Buildroot] [PATCH 06/11] package/libopenssl: extend m68k ColdFire support

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
Cc: buildroot@buildroot.org, Bernd Kuhls <bernd@kuhls.net>,
	 Fabrice Fontaine <fontaine.fabrice@gmail.com>,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	 Ismael Luceno <ismael@iodev.co.uk>,
	Romain Naour <romain.naour@gmail.com>
Subject: Re: [Buildroot] [PATCH 06/11] package/libopenssl: extend m68k ColdFire support
Date: Fri, 29 May 2026 15:31:53 +0200	[thread overview]
Message-ID: <ahmScNri2ZIPLaVG@windsurf> (raw)
In-Reply-To: <20260424132326.825570-7-jeanmichel.hautbois@yoseli.org>

Hello Jean-Michel,

On Fri, Apr 24, 2026 at 03:23:21PM +0200, Jean-Michel Hautbois wrote:
> ColdFire has no hardware atomic instructions. Disable OpenSSL's
> atomic operations and inline assembly which assume a different m68k
> variant, and add -fno-strict-aliasing to prevent GCC from optimizing
> away type-punned pointer accesses used in OpenSSL internals.
> 
> Link with libatomic for the 64-bit atomic operations that OpenSSL 3.x
> requires, and force the linux-generic32 target to avoid arch-specific
> assembly paths.
> 
> Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org>
> ---
>  package/libopenssl/libopenssl.mk | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/libopenssl/libopenssl.mk b/package/libopenssl/libopenssl.mk
> index bd4b889c88..6009cbb345 100644
> --- a/package/libopenssl/libopenssl.mk
> +++ b/package/libopenssl/libopenssl.mk
> @@ -23,6 +23,9 @@ ifeq ($(BR2_m68k_cf),y)
>  LIBOPENSSL_CFLAGS += -mxgot
>  # resolves an assembler "out of range error" with blake2 and sha512 algorithms
>  LIBOPENSSL_CFLAGS += -DOPENSSL_SMALL_FOOTPRINT
> +LIBOPENSSL_CFLAGS += -DOPENSSL_NO_ATOMICS -DOPENSSL_NO_ASM -fno-strict-aliasing
> +LIBOPENSSL_CONF_ENV += LDFLAGS="-latomic"
> +LIBOPENSSL_TARGET_ARCH = linux-generic32

Why is this needed now? It is correctly building at least for existing
Coldfire platforms that we support (I believe).

If it needs -latomic, it would most likely need that on other
architectures like Sparc for which atomic built-ins are implemented in
libatomic.

So essentially the problem that I see with your patch that it is
"just" fixing your particular issue in your particular case, but not
really taking a step back and see to which cases which fix/workaround
should apply. For example the -fno-strict-aliasing thing, why is that
Coldfire specific?

Also, have a look at config BR2_PACKAGE_LIBOPENSSL_TARGET_ARCH, it
should already use "linux-generic32 no-asm", which is basically what
you're doing here. Except perhaps you have
BR2_TOOLCHAIN_HAS_LIBATOMIC, which is why "linux-latomic no-asm" gets
used instead?

As you can see, a bit more investigation is needed to have a cleaner
solution.

Thanks!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot