On Wed, Jul 1, 2026 at 9:12 AM Trupti <[email protected]> wrote: > > Dear Maintainer, > > The version 3.14.0+ds-1 still FTBFS on ppc64el despite the fix uploaded > for this bug. > Build log: > https://buildd.debian.org/status/fetch.php?pkg=supercollider-sc3-plugins&arch=ppc64el&ver=3.13.0%7Erepack-1.2&stamp=1782753041&raw=0 > > > Root cause: > Removing -mno-altivec/-mno-vsx in 3.14.0+ds-1 re-enabled AltiVec/VSX on > ppc64el, > exposing a pre-existing defect in two bundled nova-simd headers: > > external_libraries/nova-simd/vec/vec_altivec.hpp > external_libraries/nova-simd/vec/vec_int_altivec.hpp > > current falling build log : > https://buildd.debian.org/status/fetch.php?pkg=supercollider-sc3-plugins&arch=ppc64&ver=3.14.0%2Bds-1&stamp=1782852658&raw=0 > > > Both include <altivec.h> and immediately open a C++ namespace. > On ppc64el, GCC defines __APPLE_ALTIVEC__, which causes <altivec.h> to > skip its #define vector __vector macro. > The bare vector keyword then reaches the C++ parser directly, and inside > a namespace where std::vector is also visible, > GCC 15 fails with: > > error: 'vector' does not name a type; did you mean 'vec_or'? > 30 | typedef vector float fvec; > > > Fix: > Replaced all bare vector usages inside the affected namespaces with > __vector — GCC's built-in keyword, > valid at any scope regardless of __APPLE_ALTIVEC__. Added #undef > vector/#undef pixel/#undef bool after #include <altivec.h> > as a defensive guard. Also fixed vec_re(arg) → vec_re(arg.data_), since > the intrinsic requires a raw __vector float, not the wrapper class.
This is how we handle it in Crypto++ [0]. I would not worry about __APPLE_ALTIVEC__. __ALTIVEC__ picks up the use case. In an implementation file that needs the definitions: // could use -maltivec, -mcpu=power7, -mcpu=power8, etc #if defined(__ALTIVEC__) || defined(_ARCH_PWR7) # include "ppc_simd.h" #endif And then at the head of ppc_simd.h: [1] #if defined(__ALTIVEC__) # include <altivec.h> # undef vector # undef pixel # undef bool #endif And then in the same ppc_simd.h file: #if defined(__ALTIVEC__) || defined(CRYPTOPP_DOXYGEN_PROCESSING) /// \brief Vector of 8-bit elements typedef __vector unsigned char uint8x16_p; /// \brief Vector of 16-bit elements typedef __vector unsigned short uint16x8_p; /// \brief Vector of 32-bit elements typedef __vector unsigned int uint32x4_p; #if defined(__VSX__) || defined(_ARCH_PWR8) || defined(CRYPTOPP_DOXYGEN_PROCESSING) /// \brief Vector of 64-bit elements typedef __vector unsigned long long uint64x2_p; #endif // VSX or ARCH_PWR8 #endif // __ALTIVEC__ or Doxygen Now use the typedefs like uint8x16_p, uint16x8_p, uint32x4_p, and uint64x2_p. > Verified on a ppc64el LPAR (Debian sid): > dpkg-buildpackage -us -uc -b successfully builds supercollider on > ppc64el generating below .dep files > > ladspalist_3.14.0+ds-3_ppc64el.deb > sc3-plugins-server_3.14.0+ds-3_ppc64el.deb > ladspalist-dbgsym_3.14.0+ds-3_ppc64el.deb > sc3-plugins-server-dbgsym_3.14.0+ds-3_ppc64el.deb > sc3-plugins_3.14.0+ds-3_all.deb > sc3-plugins-language_3.14.0+ds-3_all.deb > > I have shared two patches below, please review it. > > I will create a Merge Request on Salsa with this patch if it looks good > to you. > > Please let me know if any changes are needed. [0] https://cryptopp.com/ [1] https://github.com/weidai11/cryptopp/blob/master/ppc_simd.h Jeff
