All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fabrice Fontaine <fontaine.fabrice@gmail.com>
To: buildroot@buildroot.org
Cc: Romain Naour <romain.naour@gmail.com>,
	Giulio Benetti <giulio.benetti@benettiengineering.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Fabrice Fontaine <fontaine.fabrice@gmail.com>
Subject: [Buildroot] [PATCH v2, 1/1] toolchain/Config.in: update BR2_TOOLCHAIN_HAS_LIBATOMIC dependencies
Date: Sun, 12 May 2024 12:05:24 +0200	[thread overview]
Message-ID: <20240512100524.15346-1-fontaine.fabrice@gmail.com> (raw)

Update BR2_TOOLCHAIN_HAS_LIBATOMIC dependencies to avoid the following
build failure with libopenssl and
BR2_TOOLCHAIN_EXTERNAL_BOOTLIN_ARMV7M_UCLIBC_STABLE:

/home/buildroot/autobuild/run/instance-2/output-1/host/opt/ext-toolchain/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: ./libcrypto.a(libcrypto-lib-threads_pthread.o): in function `CRYPTO_atomic_or':
threads_pthread.c:(.text+0xfa): undefined reference to `__atomic_is_lock_free'

libatomic is available since gcc 4.8, when thread support is enabled.
However, the gcc logic in libatomic/configure.tgt does not recognize
"uclinux" as a valid OS part of the target tuple, and therefore it
does not build libatomic. The "uclinux" part of the tuple is used by
Buildroot when BR2_BINFMT_FLAT=y [1]. This broken logic has only been
fixed for arm since gcc 10.1.0 [2].

Indeed, bootlin armv7m is an uclibc toolchain compiled with atomic
support through libatomic.

[1] https://git.buildroot.net/buildroot/commit/?id=b3d1fb26dcadd8c570e2c415ce05398ecc810b32
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b1e21e5a5d19b436f948710e09157c5b3244f541

Fixes:
 - http://autobuild.buildroot.org/results/d25e898f9715bf6a21284807361a57735a7a2e1d
 - http://autobuild.buildroot.org/results/e37ed5ad6ba41d610bffe9c234f699e203ef5069

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
Changes v1 -> v2 (after review of Thomas Petazzoni):
 - Update dependencies to enable libatomic with uclibc only on arm with
   gcc 10

 toolchain/Config.in | 18 +++++++++++-------
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/toolchain/Config.in b/toolchain/Config.in
index 655f1a53dc..ef8a8ba381 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -888,15 +888,19 @@ config BR2_TOOLCHAIN_HAS_SYNC_8
 	default y if BR2_TOOLCHAIN_ARM_HAS_SYNC_8
 	default y if BR2_TOOLCHAIN_X86_HAS_SYNC_8
 
-# libatomic is available since gcc 4.8, when thread support is
-# enabled. Also, libatomic doesn't recognize "uclinux" as a valid OS
-# part of the tuple, and is therefore not build on uclinux targets,
-# which is why BR2_BINFMT_FLAT configurations are excluded.
+# libatomic is available since gcc 4.8, when thread support is enabled.
+# However, the gcc logic in libatomic/configure.tgt does not recognize
+# "uclinux" as a valid OS part of the target tuple, and therefore it
+# does not build libatomic. The "uclinux" part of the tuple is used by
+# Buildroot when BR2_BINFMT_FLAT=y. This broken logic has only been
+# fixed for arm since gcc 10.1.0. 
 config BR2_TOOLCHAIN_HAS_LIBATOMIC
 	bool
-	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8 && \
-		BR2_TOOLCHAIN_HAS_THREADS && \
-		!BR2_BINFMT_FLAT
+	default y if BR2_TOOLCHAIN_GCC_AT_LEAST_4_8
+	depends on BR2_TOOLCHAIN_HAS_THREADS
+	depends on BR2_BINFMT_ELF || \
+		(BR2_BINFMT_FLAT && BR2_arm && \
+		BR2_TOOLCHAIN_GCC_AT_LEAST_10)
 
 # __atomic intrinsics are available:
 # - with gcc 4.8, either through built-ins or libatomic, on all
-- 
2.43.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

             reply	other threads:[~2024-05-12 10:05 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-12 10:05 Fabrice Fontaine [this message]
2024-05-12 10:16 ` [Buildroot] [PATCH v2, 1/1] toolchain/Config.in: update BR2_TOOLCHAIN_HAS_LIBATOMIC dependencies Thomas Petazzoni via buildroot
2024-06-08 11:13 ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240512100524.15346-1-fontaine.fabrice@gmail.com \
    --to=fontaine.fabrice@gmail.com \
    --cc=buildroot@buildroot.org \
    --cc=giulio.benetti@benettiengineering.com \
    --cc=romain.naour@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.