Hi,
On 2022-08-31 08:04, Bo YU wrote:
> Source: gcc-12
> Version: 12.2.0-1
> Severity: important
> X-Debbugs-Cc: debian-riscv@lists.debian.org
>
> Dear gcc Maintainer,
>
> Since glibc 2.34 we need to link libatomic explicitly to fix
> huge amount issues that has ftbfs on riscv64.
>
> The detailed explanation is here[0]:
>
> ```
> ... linking with -pthread automatically links with libatomic,
> however the recent upload of glibc 2.34 made the -pthread flag
> not fully necessary anymore, and cmake decided to stop using it.
> The workaround is to explicitly link with libatomic
> ```
> We have sent numerous patches to fix this issue[1]. But it is
> obvious that, in the past, using the pthread flag in cmake to
> link libatomic, there will be trouble after rebuild like [2].
>
> The workground is *stolen* from Arch linux gcc patch:
> https://github.com/felixonmars/archriscv-packages/blob/master/gcc/riscv64.patch#L65
The idea of using the same spec as with -pthread unconditionally has
been discussed on the IRC channel a few days ago. It seems there was a
reason for limiting the link with -latomic to pthread, but that has been
discussed internally before the patch submission to GCC, and has been
lost.
Anyway this is probably something to try, but the way is done in Arch,
i.e. patching the binaries, is ugly. It's probably better to patch the
sources that way (completely untested):
diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
--- a/gcc/config/riscv/linux.h
+++ b/gcc/config/riscv/linux.h
@@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see
#undef LIB_SPEC
#ifdef LD_AS_NEEDED_OPTION
#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC \
- " %{pthread:" LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION "}"
+ LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
#else
#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC " -latomic "
#endif
> So can we try it? I am not gcc expert and unable to evaluate
> the workround how trouble if enabled in Debian. Or there are
> other better solutions?
The better solution would be for someone to continue the work from this
patch, but that is a lot more work:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283119.html
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Attachment:
signature.asc
Description: PGP signature