Hello, looking at the build log for armhf:
https://buildd.debian.org/status/fetch.php?pkg=pcp&arch=armhf&ver=7.1.1-1&stamp=1774834628&raw=0

make[1]: Entering directory '/build/reproducible-path/pcp-7.1.1'
export QT_SELECT=5; \
./configure --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc --localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default --with-zip=/bin/gzip --with-tar=/bin/tar SED=/bin/sed ECHO=/bin/echo QMAKE=/usr/bin/qmake MAKEDEPEND=/bin/true BZIP2=/bin/bzip2 --with-non-debug=yes
checking build system type... armv8l-unknown-linux-gnueabihf
checking host system type... armv8l-unknown-linux-gnueabihf
checking target system type... armv8l-unknown-linux-gnueabihf
Building on armv8l-unknown-linux for armv8l-unknown-linux

This makes the package built for a wrong arch in armhf.
The baseline should be armv7l

(not sure if this is really an autoconf bug)

G.

I don't believe this is a PCP bug.  Our build calls

    dh_update_autotools_config

which AFIACT installs a new config.sub and this seems to be where the armv8l is coming from for your armhf build.

On the other platforms that I can easily check, the new config.sub has cpu=armv7l, e.g,

kenj@bozo:~/src/pcp$ grep armv build/deb/pcp-7.1.2/config.sub
				basic_machine=armv4l-rebel
		cpu=armv7l
			| arm | arm[lb]e | arme[lb] | armv* \

Hello
this way you are missing the dh flags injected to the configure script, such as
--build=arm-linux-gnueabihf 


I see by changing the configure to dh_auto_configure a better config log:
dh_auto_configure -- --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc --localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default --with-zip=/bin/gzip --with-tar=/bin/tar SED=/bin/sed ECHO=/bin/echo QMAKE=/usr/bin/qmake MAKEDEPEND=/bin/true BZIP2=/bin/bzip2 --with-non-debug=yes
./configure --build=arm-linux-gnueabihf --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/arm-linux-gnueabihf --libexecdir=\${prefix}/lib/arm-linux-gnueabihf --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc --localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default --with-zip=/bin/gzip --with-tar=/bin/tar SED=/bin/sed ECHO=/bin/echo QMAKE=/usr/bin/qmake MAKEDEPEND=/bin/true BZIP2=/bin/bzip2 --with-non-debug=yes
checking build system type... arm-unknown-linux-gnueabihf
checking host system type... arm-unknown-linux-gnueabihf
checking target system type... arm-unknown-linux-gnueabihf
Building on arm-unknown-linux for arm-unknown-linux
Build: os=linux cpu=arm
Target: os=linux cpu=arm
configure: Compiling with the NDEBUG macro set (non-debug)
checking for pkg-config... /usr/bin/pkg-config



instead of:
export QT_SELECT=5; \
./configure --prefix=/usr --libexecdir=/usr/lib --sysconfdir=/etc --localstatedir=/var --with-rcdir=/etc/init.d --with-sysconfigdir=/etc/default --with-zip=/bin/gzip --with-tar=/bin/tar SED=/bin/sed ECHO=/bin/echo QMAKE=/usr/bin/qmake MAKEDEPEND=/bin/true BZIP2=/bin/bzip2 --with-non-debug=yes
checking build system type... armv7l-unknown-linux-gnueabihf
checking host system type... armv7l-unknown-linux-gnueabihf
checking target system type... armv7l-unknown-linux-gnueabihf
Building on armv7l-unknown-linux for armv7l-unknown-linux
Build: os=linux cpu=armv7l
Target: os=linux cpu=armv7l
configure: Compiling with the NDEBUG macro set (non-debug)



the patch is quite simple:
--- pcp-7.1.1/debian/rules 2026-02-19 06:55:36.000000000 +0100
+++ pcp-7.1.1/debian/rules 2026-04-24 16:15:07.000000000 +0200
@@ -17,7 +17,7 @@
export DIST_ROOT = $(here)/debian/pcp
export NO_CHOWN=true

You are correct, thanks for pointing this out and for the triage effort.

It is even simpler than that.  Our Debian build sits underneath a build infrastructure that builds packages for all manner of operating systems and distributions, so the $(configure_tools) part is still needed by that upper build infrastructure.

I believe simply replacing the direct call to ./configure with dh_auto_configure -- resolves your issue, but unfortunately I don't have any environment where I can test build for arm.

Also unfortunately, this change just missed the latest pcp-7.1.2 upload to Debian, so it will have to wait for the next upload and I don't have a firm date for that as yet.

Cheers, and thanks once again for your help.

Hello

thanks for confirming

ok I was trying to remove that hack, but if this is needed, ok

there are porterboxes, and yes, it does fix the issue.

Unfortunately it isn't that simple. Fixing the configure script will have a side effect of making it FTBFS on armhf.
I don't remember exactly the code, but I remember some #ifdefs specific for arm > 7, and then failing to compile there.

My guess is that we need probably ask for a removal of armhf binaries, they are wrongly built right now (will
raise SIGILL on real armhf hardware), nobody noticed (probably not many users there?) and the porting work
might be not trivial for an "old" architecture such as armhf

from Ubuntu log:

https://launchpadlibrarian.net/856036763/buildlog_ubuntu-resolute-armhf.pcp_7.1.1-1_BUILDING.txt.gz
gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection -fdebug-prefix-map=/<<PKGBUILDDIR>>=/usr/src/pcp-7.1.1-1 -I./src/include -I./src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../src/include -I../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../../src/include -I../../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../../../src/include -I../../../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -I../../../src/pmcd/src -I../../../src/libpcp/src -DPMCD_INTERNAL -Wall -O2 -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -c -o data.o data.c
gcc -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -fno-stack-clash-protection -fdebug-prefix-map=/<<PKGBUILDDIR>>=/usr/src/pcp-7.1.1-1 -I./src/include -I./src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../src/include -I../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../../src/include -I../../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -Wall -O2 -g -I../../../src/include -I../../../src/include/pcp -DPCP_VERSION=\"7.1.1\" -fPIC -fno-strict-aliasing -D_GNU_SOURCE -DNDEBUG -Wshadow -Wno-array-bounds -I../../../src/pmcd/src -I../../../src/libpcp/src -DPMCD_INTERNAL -Wall -O2 -g -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=3 -c -o trace.o trace.c
/tmp/ccAfd1mp.s: Assembler messages:
/tmp/ccAfd1mp.s:253: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:308: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:428: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:524: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:645: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:766: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:869: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:953: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:1056: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:1199: Error: unrecognized symbol type ""
/tmp/ccAfd1mp.s:1319: Error: unrecognized symbol type ""
make[4]: *** [<builtin>: trace.o] Error 1
make[3]: *** [GNUmakefile:28: default] Error 2
make[2]: *** [GNUmakefile:164: default_pcp] Error 2
thank you for the prompt reaction!

Gianfranco

G'day Gianfranco,

Well I'm stuck.  I cannot reproduce and

$ grep -ri '^#if.*arm'

across the whole source tree does not reveal anything.

Is it possible that the fist full of gcc options we've collected over 35 years on mips, ia64 and x86_64 include something that's deadly for armhf?  Do any of these ring warning bells?


So I'm not sure what you're suggesting here ... is this in Debian or Ubuntu or both?

And how would one prosecute such a request? [sorry Debian processes and workflows is not my strong suit, despite using a Ubuntu system for most of my development, and most of the other PCP developers are off in RedHat land, so not a lot of traction there either].

For others, this failure is in libpcp_trace.

Hello,

Not sure sorry!

I'm suggesting to fix this bug, and check if Debian armhf start failing also or not.
This might be due to new gcc/new glibc/new toolchain/new binutils/new flags (Ubuntu only).

Based on what happens in Debian, we can try to fix or drop the arch.

Fix the configure, upload in Debian, eventually fix armhf or drop the architecture as it was done in Ubuntu.

G.

According to https://buildd.debian.org/status/package.php?p=pcp the latest pcp-7.1.2-1 (which does NOT contain the dh_auto_configure change) was built and installed OK on armhf, but I guess your point is that unless someone actually tries to execute binaries from this build, they'll never see the wrong armv8l arch.

I'll keep a eye on this the next time pcp is uploaded to Debian to see if the armhf build works and update this but then.  At this stage I do not have a target date for the next pcp upload to Debian.

Hello,

exactly, runtime SIGILL, seen in Ubuntu because the armhf binaries are built on real armv7 hardware, so the configure works even if it is not correctly passing the "--host" flag :)

Debian builds armhf on top of arm64 builders (not sure if all or just some of them), so this build failure might be sporadic when an old builder picks pcp up on armhf, but still an RC bug in Debian

We can still upload this fix as is right now, without having to wait for a new release, don't forget that the
package might be autoremoved from testing

G.

We believe that the bug you reported is fixed in the latest version of
pcp, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1133063@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Nathan Scott <nathans@debian.org> (supplier of updated pcp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 01 May 2026 23:59:32 +1100
Source: pcp
Architecture: source
Version: 7.1.3-2
Distribution: unstable
Urgency: high
Maintainer: PCP Development Team <pcp@groups.io>
Changed-By: Nathan Scott <nathans@debian.org>
Closes: 1133063
Changes:
 pcp (7.1.3-2) unstable; urgency=high
 .
   * New release (full details in CHANGELOG).
   * Use dh_auto_configure in preference to ./configure (closes: #1133063)
Checksums-Sha1:
 2aa3ac0258988a229b663f1419a6640b4689d58e 5746 pcp_7.1.3-2.dsc
 c289ca8f6f40dd9f265bae2771259f3118302e10 35029009 pcp_7.1.3.orig.tar.gz
 c60f1be63e811476c5b4d07b4bfdad1d8c82f038 34488 pcp_7.1.3-2.debian.tar.xz
 cd632b806335322e273ba9c4e1a2c82ed5275522 16362 pcp_7.1.3-2_source.buildinfo
Checksums-Sha256:
 c66e49c34491f36e55e925f68bd3e996eb9a5e58befc8b4a795cce6c94672cc7 5746 pcp_7.1.3-2.dsc
 305b1171156ff1a99a35cfdede9b5e83beb7fc399e807549d1878076861d2704 35029009 pcp_7.1.3.orig.tar.gz
 2a90b1ffaec1235a6c6d8a21b72bcf5fee489df910293f8d410892faac3eef34 34488 pcp_7.1.3-2.debian.tar.xz
 dba20236178c07343ca9dd63fa291230cccd737d78a2fb270d687a9e8271c8d5 16362 pcp_7.1.3-2_source.buildinfo
Files:
 ae3901064d91079cb85398320d9f437e 5746 utils optional pcp_7.1.3-2.dsc
 6bb4c1bdc0091111fce07626caa89408 35029009 utils optional pcp_7.1.3.orig.tar.gz
 fa27c8b0cc74499afba26f9307c40414 34488 utils optional pcp_7.1.3-2.debian.tar.xz
 9ef0bed0cdb543ef81ae2b1392b74211 16362 utils optional pcp_7.1.3-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE96vodh5v5oY45ig6/ghC7jbdjAwFAmn2DxUACgkQ/ghC7jbd
jAyyxg/+LyUTmORnM81FWfxFrZ00ix26kNDF29ahMamHMDWRTpD9JcCQf+xhZ6vY
zxR36hghqNXoT3wN80eyYg6EYDf60D+OtTyfCn9bqRnE7FT0j5FCv6snnDWpVkCk
7z84YCUz5lEeyC0sUIFpNReqJ9/SifYdgWyx1IOHkvUq/24KKh1X7RG2JJHRH2OL
IxDHSdneYenUU+t0mCuc8CU8I9+HXjS48n86TNFUb1x/rjsqIwQcJ9OTkqMI9jIR
rWilzEGIeeRvh8ZxMRZ6B3Mcdnh/U2nF3WZhd1PmO7IR4n65WBHDAtUO2Yu7QYH8
vHSN01sDPG7UfHFhsc9JfxA0HX2m8rP2eTQshVyUGLUVxWvKDzBbI+znLUEEAZdF
lqQW1tWExxWzB+IDQPNhzLmDyzc66XnmE4fWeeS+s8zb9p3IOvQy751GMX1fmYn1
OmjLWcv93CHIxyn1nLGhbHXufF14h/AbxCuAZap5f3rBFgqBwIK6yp5sQ8A4OsSy
+CNCfFaCRYeG+xv5vjPexoFGXXAc3tMxItAzLHcQWv9aTX3n/txrFkfSp0tLCtNl
JFmyxys5Q5zGWdrOwIdH1GwzyHrPVI9DSJeMo4Z+Jp+rAvDXAEjIquUytPPhwwKc
Hofq8QpjfCNTi3xZDXXkvr7M7k6lRhz0GmzoBpFNQ5FM6BT/NjE=
=YOZZ
-----END PGP SIGNATURE-----

For some strange reason, this bug continues to be listed as one cause
for pcp autoremoval despite being closed, and despite pcp-7.1.5 being
in both testing and unstable.

Build looks clean: https://buildd.debian.org/status/package.php?p=pcp

If anyone can solve this mystery, we'd love to hear the explanation.

Thanks!

[..]

The bug was marked fixed in version 7.1.3-2. However the current
src:pcp changelog does not include the changelog for 7.1.3-2, thus
the BTS assumes this fix does not apply to the pcp in unstable
(normally this situation implies the fix applies to another branch).

https://sources.debian.org/src/pcp/7.1.5-1/debian/changelog

Either you move the fixed versions or you fix the changelog.

Chris

Ah, thanks Chris - that makes sense, the -2 release was a procedural
botch on my end.  I'll move the fixed version.

cheers.

Closing this bug as it has been successfully fixed in version 7.1.5-1 of pcp.