Re: Help with codeblocks ppc64el specific FTBFS

On Wed, Mar 25, 2026 at 04:38:10PM -0700, Vincent Cheng wrote:
> On Wed, Mar 25, 2026 at 4:28 PM Jeffrey Walton <[email protected]> wrote:
> >
> > On Wed, Mar 25, 2026 at 5:05 PM Vincent Cheng <[email protected]> wrote:
> > >
> > > Hello,
> > >
> > > I'm not subscribed to the list; please cc me on all replies.
> > >
> > > codeblocks/25.03+dfsg-2 [1] was the last version built successfully on
> > > ppc64el (timestamp 2025-04-30 21:52:21).
> > > codeblocks/25.03+dfsg-2+b1 [2] was the first build that started
> > > failing (binNMU with no source changes, timestamp 2026-01-16
> > > 14:45:49), and all subsequent builds have failed with the same linker
> > > error.
> > >
> > > As far as I can tell, the error appears to be the following:
> > >
> > > /usr/bin/ld: /usr/lib/gcc/powerpc64le-linux-gnu/15/libgcc.a(float128-ifunc.o):(.data+0x0):
> > > undefined reference to `__parse_hwcap_and_convert_at_platform'
> > > collect2: error: ld returned 1 exit status
> > >
> > > src:codeblocks is not failing on any other arch so this appears to be
> > > a ppc64el toolchain specific issue, which is outside of my area of
> > > expertise. Does anyone have suggestions for how to fix this? As
> > > another data point, it looks like the package builds fine on Ubuntu
> > > ppc64el, so this is somehow specific to Debian's toolchain? Thanks for
> > > any tips/pointers!
> > >
> > > Regards,
> > > Vincent
> > >
> > > [1] https://buildd.debian.org/status/fetch.php?pkg=codeblocks&arch=ppc64el&ver=25.03%2Bdfsg-2&stamp=1746049941&raw=0
> > > [2] https://buildd.debian.org/status/fetch.php?pkg=codeblocks&arch=ppc64el&ver=25.03%2Bdfsg-2%2Bb1&stamp=1768574749&raw=0
> >
> > It looks like __parse_hwcap_and_convert_at_platform is part of Glibc
> > 2.23 on powerpc:
> > <https://git.zx2c4.com/glibc/tree/sysdeps/powerpc/Versions>.
> >
> > According to <https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2026-February/140716.html>:
> >
> >     This failure was first reported against gcc-15, but further analysis
> >     showed that it is not a GCC bug.
> >
> >     The issue lies in the package’s build system, which does not correctly
> >     handle runtime library linking with newer GCC versions.
> >
> > I have this in my notes, but I don't know who to give credit to.  Maybe Adrian?

(not sure which Adrian this was referring to, it wasn't me)

> >     ifeq ($(DEB_HOST_ARCH),ppc64el)
> >     export DEB_LDFLAGS_MAINT_APPEND += -lgcc -lgcc_s -lc
> >     endif
> 
> Thanks, this works perfectly on a ppc64el porterbox.

I fixed #468555, it is now possible to do the change below to avoid
hardcoding gcc library internals.

> Regards,
> Vincent

cu
Adrian


--- codeblocks-25.03+dfsg/debian/rules	2026-03-26 02:38:31.000000000 +0200
+++ codeblocks-25.03+dfsg/debian/rules	2026-03-26 02:38:31.000000000 +0200
@@ -15,12 +15,6 @@
 
 export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -ltinyxml
 
-# ppc64el FTBFS due to `undefined symbol __parse_hwcap_and_convert_at_platform`
-# https://lists.debian.org/debian-powerpc/2026/03/msg00032.html
-ifeq ($(DEB_HOST_ARCH),ppc64el)
-export DEB_LDFLAGS_MAINT_APPEND += -lgcc -lgcc_s -lc
-endif
-
 # Disable WXDEBUG checks, which wx3.0 defaults to enabling but were off by
 # default in wx2.8, to address issues such as #736368.
 # Also enable reproducible builds by ensuring that timestamps are reproducible;
@@ -37,6 +31,7 @@
 	touch $(CURDIR)/debian/codeblocks-headers.install.wx30
 	
 	dh_auto_configure -- --with-contrib-plugins=all,-FileManager \
+	                     --enable-cxx-stdlib \
 	                     --disable-silent-rules \
 	                     --libdir=\$${exec_prefix}/lib