Your message dated Sat, 20 May 2023 13:11:49 +0200
with message-id <ZGiq9R/p+gpec...@aurel32.net>
and subject line Bug#1018799: gcc-12: Workround for fixing -latomic issue on
riscv64 after glibc2.34
has caused the Debian Bug report #1018799,
regarding gcc-12: Workround for fixing -latomic issue on riscv64 after glibc2.34
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1018799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018799
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: gcc-12
Version: 12.2.0-1
Severity: important
X-Debbugs-Cc: debian-ri...@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
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?
Welcome Comments here.
Please feel free to change severity if it is inappropriate.
[0]: https://lists.debian.org/debian-riscv/2022/08/msg00028.html
[1]:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debian-riscv%40lists.debian.org&tag=riscv64
[2]:
https://buildd.debian.org/status/fetch.php?pkg=opentracing-cpp&arch=riscv64&ver=1.6.0-3&stamp=1661892134&raw=0
--
Regards,
--
Bo YU
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Version: 13.1.0-3
On 2022-08-31 08:04, Bo YU wrote:
> Source: gcc-12
> Version: 12.2.0-1
> Severity: important
> X-Debbugs-Cc: debian-ri...@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
>
> 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?
>
> Welcome Comments here.
>
> Please feel free to change severity if it is inappropriate.
This has been fixed in gcc-13 version 13.1.0-3. Closing the bug
accordingly.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
signature.asc
Description: PGP signature
--- End Message ---
