Hi Reinhard,
thanks for triggering this build. The arm64 problem seems to be a
platform-specific incompatibility between the clang parser used by
AspectC++ and gcc header files. It occurs in the build process *after*
ac++ has been built successfully during a test (the compilation of the
Puma library).
I learned here
(https://bugs.launchpad.net/ubuntu/+source/mumax3/+bug/2032624) that
aspectc++ is not the only package with this problem. The root cause is
that we use the gcc preprocessor configuration combined with clang's
libraries to actually parse the code. One could say that this is a dirty
hack, but in the case of AspectC++ it is hardly avoidable. Otherwise we
wouldn't be able to support "aspect weaving" into code that is compiled
with a gcc-based cross compiler. We also would have to force users to
install clang header files even if they don't use clang (directly).
As a very quick workaround we could allow for the Puma test to fail.
In parallel I could look into a better workaround. Unfortunately, I
haven't been able to find the source code of the file in which the error
occurs. Can you help? It seems to be this code fragment:
#if __GNUC_PREREQ(9, 0)
# define __ADVSIMD_VEC_MATH_SUPPORTED
typedef __Float32x4_t __f32x4_t;
typedef __Float64x2_t __f64x2_t;
#elif __glibc_clang_prereq(8, 0)
# define __ADVSIMD_VEC_MATH_SUPPORTED
typedef __attribute__ ((__neon_vector_type__ (4))) float __f32x4_t;
typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
#endif
If this is the right code, I could check for the arm64 platform and GCC
>= 9 in AspectC++. In this case I could internally create typedefs for
__Float32x4_t and __Float64x2_t in a way that is compatible with the
clang parser, namely ...
typedef __attribute__ ((__neon_vector_type__ (4))) float __Float32x4_t;
typedef __attribute__ ((__neon_vector_type__ (2))) double __Float64x2_t;
It is also not a perfectly clean solution, but might work for AspectC++.
What do you think?
Best regards,
Olaf
Am 07.12.24 um 14:42 schrieb Reinhard Tartler:
Hi Olaf,
Good news, aspectc++ built on most platforms in Debian :-)
https://buildd.debian.org/status/package.php?p=aspectc%2B%2B
On 2024-12-06 20:34, Adrian Bunk wrote:
Control: reopen -1
On Fri, Dec 06, 2024 at 01:21:04PM +0000, Debian Bug Tracking System
wrote:
...
aspectc++ (1:2.3+git20241206-1) unstable; urgency=medium
.
* New upstream version 2.3+git20241206
...
- Fixes build on arm64, closes: #1070443
...
Weaving aspects into PreExprParser.cc...
Weaving aspects into PreParser.cc...
Generating library header files...
In file included from cpp/PreExprParser.lem:56:
In file included from /usr/include/c++/13/math.h:36:
In file included from /usr/include/c++/13/cmath:47:
In file included from /usr/include/math.h:40:
/usr/include/aarch64-linux-gnu/bits/math-vector.h:30:9: error: unknown
type name '__Float32x4_t'
typedef __Float32x4_t __f32x4_t;
^
/usr/include/aarch64-linux-gnu/bits/math-vector.h:31:9: error: unknown
type name '__Float64x2_t'
typedef __Float64x2_t __f64x2_t;
^
1:2.3+git20241206-1 does still FTBFS:
https://buildd.debian.org/status/fetch.php?pkg=aspectc%2B%2B&arch=arm64&ver=1%3A2.3%2Bgit20241206-1&stamp=1733492435&raw=0
Except arm64.
Any idea why only arm64 would be affected?
I do see that the arm64 build is using a newer package revision
(g++-14_14.2.0-9 instead of g++-14_14.2.0-8 as on amd64).
I would be very surprised if that minor update would cause such an
compilation issue though. However, here is the changelog:
https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-14-debian/debian/changelog
-rt
