From: leahneukirchen <leahneukirchen@users.noreply.github.com>
To: ml@inbox.vuxu.org
Subject: Re: [ISSUE] [CLOSED] [RFC] How to progress with gcc and libatomic
Date: Fri, 14 Jun 2024 16:03:16 +0200 [thread overview]
Message-ID: <20240614140316.98DF42AB76@inbox.vuxu.org> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-35992@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 2511 bytes --]
Closed issue by leahneukirchen on void-packages repository
https://github.com/void-linux/void-packages/issues/35992
Description:
I'm suggesting this change because I want to bring the RISC-V port forward, but the problem also affects us already on armv6 in some way.
In short: for certain operations, gcc generates calls to its own library of atomic functions, `libatomic`. Where exactly depends on the architecture and how powerful the instruction-set atomics are, but for example:
- On aarch64 and x86_64, for atomic 128-bit ints or double complex numbers.
- On armv6, for any C11 _Atomic integer type.
- On RISC-V 64-bit, for *any* code that uses `-pthread`.
The problem is: gcc doesn't link against libatomic automatically in these cases.
Code that uses more than 64-bit atomics usually uses libatomic upstream (because all platforms are affected), so this is not our problem.
For armv6 and other platforms, we currently use `$XBPS_TARGET_NO_ATOMIC8` in roughly 150 templates. This is annoying, but bearable, and we did the work already.
For RISC-V, this is unacceptable, as we need to touch way too many templates to adjust every package using pthreads.
I therefore suggest a two-step solution:
1. Add `libatomic-devel` as a `depends=` of gcc. This will ensure code that knows it needs `-latomic` will just work without further changes. As `libatomic-devel` is a small subpackage of gcc, this doesn't change else much. It requires just a rebuild of gcc.
2. Import the `--enable-autolink-libatomic` [patch](https://git.alpinelinux.org/aports/tree/main/gcc/0039-configure-Add-enable-autolink-libatomic-use-in-LINK_.patch). This patch links to libatomic automatically, as needed. I'd suggest to enable it for the $XBPS_TARGET_NO_ATOMIC8 platforms by default, and RISC-V in the future. This patch is not merged upstream, but some distros use it, for example Alpine. It is also quite small so should not be much additional maintenance.
There is one caveat with the patch, in that it breaks building libatomic itself :clown_face:, so we also need [this Alpine patch](https://git.alpinelinux.org/aports/tree/main/gcc/0040-configure-fix-detection-of-atomic-builtins-in-libato.patch). This requires a full rebuild of all affected cross toolchains.
As a result, after step one, we can gradually remove all
```
if [ "$XBPS_TARGET_NO_ATOMIC8" ]; then
makedepends+=" libatomic-devel"
fi
```
and after step two, also all `LDFLAGS+=" -latomic"`.
next prev parent reply other threads:[~2024-06-14 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-05 12:54 [ISSUE] " leahneukirchen
2022-03-06 1:19 ` the-maldridge
2022-03-06 12:13 ` leahneukirchen
2022-06-27 2:16 ` github-actions
2022-09-26 2:15 ` github-actions
2023-01-12 21:55 ` Johnnynator
2024-06-14 5:51 ` classabbyamp
2024-06-14 14:03 ` leahneukirchen [this message]
2024-06-14 14:03 ` leahneukirchen
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=20240614140316.98DF42AB76@inbox.vuxu.org \
--to=leahneukirchen@users.noreply.github.com \
--cc=ml@inbox.vuxu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).