Your message dated Tue, 7 Jan 2025 23:09:43 +0100
with message-id <z32mj-ytypzq2...@aurel32.net>
and subject line Re: Bug#1070668: Processed: glibc: packages FTBFS caused by
vector math library header on arm64
has caused the Debian Bug report #1070668,
regarding glibc: packages FTBFS caused by vector math library header on arm64
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.)
--
1070668: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070668
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: glibc
Version: 2.38-1
Severity: important
Tags: upstream
X-Debbugs-Cc: debian-...@lists.debian.org
Control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=30909
glibc 2.38 added vector math library (libmvec) support for arm64, with
ASIMD and SVE version. This includes an architecture specific header,
/usr/include/aarch64-linux-gnu/bits/math-vector.h, to declare the
vectorized functions. For that the ASIMD types __Float32x4_t and
__Float64x2_t are also defined for GCC >= 9 or CLANG >= 8, and SVE
types __SVFloat32_t, __SVFloat64_t and __SVBool_t for GCC >= 10 and
CLANG >= 11.
Unfortunately this causes issues to the following packages:
- #1070441 cmbc: arm64 FTBFS with glibc 2.38
- #1070443 aspectc++: arm64 FTBFS with glibc 2.38
- #1070444 cxref: arm64 FTBFS with glibc 2.38
- #1070446 rocm-hipamd: arm64 FTBFS with glibc 2.38
The issue has already been reported upstream [1].
For now this file has been restored to the generic version in glibc
2.38-8, removing support for the corresponding vector functions [2].
Porters, could you please have a look at the issue, and work on fixes
at the package level and at the upstream glibc/gcc/llvm level?
Thanks
Aurelien
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30909
[2]
https://salsa.debian.org/glibc-team/glibc/-/commit/9e2889537336bdad878eef88bcfb13e457e8ea77
--- End Message ---
--- Begin Message ---
On 2024-05-12 19:54, Aurelien Jarno wrote:
> On 2024-05-07 00:29, Simon Chopin wrote:
> > As the one who reported the issue in the glibc upstream tracker, I'm now
> > of the opinion it's not a glibc bug, but rather issues with the
> > individual packages that are now FTBFS. As far as I know, this is either
> > a parser pretending to be GCC without implementing all the GCC features
> > (e.g. aspectc++), and/or a compiler targetting another platform while
> > still using the system headers (e.g. rocm-hipamd).
>
> The goal of the removal was able to progress with the migration of glibc
> 2.38 to testing to not block other packages for a long time. Anyway this
> strategy does not work for glibc 2.39 (it causes a FTBFS of glibc), so
> we have to solve the issues before being able to get glibc 2.39 to
> unstable.
>
> Among the 4 failures, cxref already got fixed. For aspectc++ and cbmc, I
> agree with you that the issues have to be fixed at the package level.
> For rocm-hipamd, the maintainer claims this is a toolchain issue...
All the affected packages have been fixed, I am therefore closing the bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://aurel32.net
--- End Message ---
