[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1018799: marked as done (gcc-12: Workround for fixing -latomic issue on riscv64 after glibc2.34)

Your message dated Sat, 20 May 2023 13:11:49 +0200
with message-id <ZGiq9R/p+gPECmLI@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 owner@bugs.debian.org
immediately.)


-- 
1018799: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018799
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

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

Attachment: 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-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
> 
> 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
aurelien@aurel32.net                     http://aurel32.net

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: