Hi,

After Boost 1.90 compatibility was fixed, only hppa still has issues:

CMake Error at /usr/lib/hppa-linux-gnu/cmake/Boost-1.90.0/BoostConfig.cmake:141 (find_package):
  Found package configuration file:

    /usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/boost_program_options-config.cmake

  but it set boost_program_options_FOUND to FALSE so package
  "boost_program_options" is considered to be NOT FOUND.  Reason given by
  package:

  No suitable build variant has been found.

  The following variants have been tried and rejected:

  * libboost_program_options.so.1.90.0 (64 bit, need 32)

  * libboost_program_options.a (64 bit, need 32)

I'd assume that this is a problem in either boost or cmake, but this
needs to be properly investigated.

   Simon

Some other 1.90.0 boost packages have the same issue and this breaks a number of other
package builds on hppa.

The issue is boost was built on a 64-bit capable hppa system (hppa64) but currently
hppa only supports 32-bit runtime.  I don't know anything about configuring boost
but I think it needs to be configured to 32-bit mode on hppa.

Dave

Some other 1.90.0 boost packages have the same issue and this breaks a number of other
package builds on hppa.

The issue is boost was built on a 64-bit capable hppa system (hppa64) but currently
hppa only supports 32-bit runtime.  I don't know anything about configuring boost
but I think it needs to be configured to 32-bit mode on hppa.

Dave

reassign 1130963 libboost-program-options1.90-dev
thanks

Hi,

Interestingly, the same thing happens on m68k. So, reassigning this to
Boost.

Thanks,
    Simon

The build failure is triggered for other dependend packages like libzypp too, e.g.:
https://buildd.debian.org/status/package.php?p=libzypp&suite=sid

Various 32-bit architectures are affected, namely: hppa, m68k, sh4 (maybe more).

Problem is, that for all 32-bit binary boost packages, the generated cmake file starts with:
# Generated by Boost 1.90.0
if(CMAKE_SIZEOF_VOID_P EQUAL 4)
   _BOOST_SKIPPED("libboost_program_options.so.1.90.0" "64 bit, need 32")
   return()
endif()

See for example /usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/libboost_program_options-variant-shared.cmake

but the package

(hppa-chroot)root@p100:/# dpkg -L libboost-program-options1.90-dev:hppa
/usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/boost_program_options-config-version.cmake
/usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/boost_program_options-config.cmake
/usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/libboost_program_options-variant-shared.cmake
/usr/lib/hppa-linux-gnu/cmake/boost_program_options-1.90.0/libboost_program_options-variant-static.cmake
/usr/lib/hppa-linux-gnu/libboost_program_options.a
/usr/lib/hppa-linux-gnu/libboost_program_options.so

actually ships (correctly) a 32-bit binary:

(hppa-chroot)root@p100:/# file -L /usr/lib/hppa-linux-gnu/libboost_program_options.so
/usr/lib/hppa-linux-gnu/libboost_program_options.so: ELF 32-bit MSB shared object, PA-RISC, 1.1 version 1
(GNU/Linux), dynamically linked, BuildID[sha1]=f681ee151d80928f58aa2a2757e0b1d72113a283, stripped

So, the generated header "if" clause is wrong for 32-bit architectures.


Adrian Bunk noted:
I don't understand immediately what jam is doing that it gets the wrong
value, but something like the following untested patch might help:

--- boost1.90-1.90.0/debian/rules	2026-04-01 07:53:39.000000000 +0300
+++ boost1.90-1.90.0/debian/rules	2026-04-01 07:53:39.000000000 +0300
@@ -174,7 +174,7 @@
  bbv2dir = $(CURDIR)/tools/build

  # With --ignore-site-config, can probably drop Build-Conflicts on boost-build.
-JAM = $(b2) $(JOBS) -q -d2 $(JAM_OPT) --layout=system --ignore-site-config --user-config=$(CURDIR)/user-config.jam debug-symbols=on
+JAM = $(b2) $(JOBS) -q -d2 $(JAM_OPT) --layout=system --ignore-site-config --user-config=$(CURDIR)/user-config.jam debug-symbols=on address-model=$(DEB_TARGET_ARCH_BITS)
  JAM_DOC = $(b2) $(JOBS) -q -d2 --ignore-site-config --user-config=$(CURDIR)/user-config-doc.jam

I can confirm, that this patch from Adrian Bunk indeed fixes the problem:
Could you please apply this patch and trigger a rebuild of boost1.90?
Thanks, Helge

--- boost1.90-1.90.0/debian/rules	2026-04-01 07:53:39.000000000 +0300
+++ boost1.90-1.90.0/debian/rules	2026-04-01 07:53:39.000000000 +0300
@@ -174,7 +174,7 @@
  bbv2dir = $(CURDIR)/tools/build

  # With --ignore-site-config, can probably drop Build-Conflicts on boost-build.
-JAM = $(b2) $(JOBS) -q -d2 $(JAM_OPT) --layout=system --ignore-site-config --user-config=$(CURDIR)/user-config.jam debug-symbols=on
+JAM = $(b2) $(JOBS) -q -d2 $(JAM_OPT) --layout=system --ignore-site-config --user-config=$(CURDIR)/user-config.jam debug-symbols=on address-model=$(DEB_TARGET_ARCH_BITS)

Dear maintainer,

I've prepared an NMU for boost1.90 (versioned as 1.90.0-6.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I should
cancel it.

   * Enable context everywhere. (Closes: #914283)
   * Build with address-model=$(DEB_TARGET_ARCH_BITS). (Closes: #1130963)
   * Stop disabling pch on arm64.
   * Disable numpy on x32 until it is available again.
   * Fix the autopkgtest for GCC 16.
   * Fix and re-enable the graph autopkgtest.
   * Remove remnants of the removed system autopkgtest.
   * Improve reproducibility.

cu
Adrian

We believe that the bug you reported is fixed in the latest version of
boost1.90, 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 1130963@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Adrian Bunk <bunk@debian.org> (supplier of updated boost1.90 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: Sun, 09 Aug 2026 21:10:47 +0300
Source: boost1.90
Architecture: source
Version: 1.90.0-6.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Boost Team <team+boost@tracker.debian.org>
Changed-By: Adrian Bunk <bunk@debian.org>
Closes: 914283 1130963
Changes:
 boost1.90 (1.90.0-6.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Enable context everywhere. (Closes: #914283)
   * Build with address-model=$(DEB_TARGET_ARCH_BITS). (Closes: #1130963)
   * Stop disabling pch on arm64.
   * Disable numpy on x32 until it is available again.
   * Fix the autopkgtest for GCC 16.
   * Fix and re-enable the graph autopkgtest.
   * Remove remnants of the removed system autopkgtest.
   * Improve reproducibility.
Checksums-Sha1:
 6ae8ac8d5ad879ebbfe1284e67a31d1e5352a786 8383 boost1.90_1.90.0-6.1.dsc
 081b0a31005b1b0399541fc5ee8fa45f0950f4d8 372300 boost1.90_1.90.0-6.1.debian.tar.xz
Checksums-Sha256:
 596e32ba7037f68287368dc31486b6414c59f6de71c1f04479e5a857ebc9d93c 8383 boost1.90_1.90.0-6.1.dsc
 ce301722034d9db70987d3f876ad670bda7581957e8842907d401078411f7af6 372300 boost1.90_1.90.0-6.1.debian.tar.xz
Files:
 a62dfaa05a0891ccfa8265523a5a5ca7 8383 libs optional boost1.90_1.90.0-6.1.dsc
 10d6d5c2265b1abc56a5b0256d93ebfb 372300 libs optional boost1.90_1.90.0-6.1.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAmp4/KAACgkQiNJCh6LY
mLEXjxAAy9ltAZiBkSfIrJO5+F/ghx8/dmUw52fsLYHxM0Mo9z600rX+/QKNogWJ
dUFRsWs5noktd3lpR0Dh0Lm49SLrg7Kb6RIc9TjM8as79VevSmOhrsw50p20PgxZ
oWc0XYSsfuVSJI+bNatZeJl2R+6fVdL/8LuNwNoXhYbSftZj850GprdZCcQkFuQ/
ByVPorzXqPd76qAJMZJfGW27FCGDv1N8M6gTdd7RO+fN08viNJi7vSv9fJ7xPrpk
ufJCQfe9tS6+CWvVprnxRZWFI9eKSJ6ErE4Jszq8bSimjlPkHFl3SyugFg1UDGDd
LgZCXAtOdPvSkXzLwc8q4AFKR3adrQNXPU/BYLxpnbDzANxqVLWCZzNycPCP5rzq
EEkR34BftE671DvorK97MdqI3qYmqN104NE+MO7kDJJR6d5kD/K/s8ZkQbG/+XJ/
62AgqZP3/xllLnNnBz7ITp6qPOur+OMfaAJz1AxxApZ2qHCPxBg+dI7c1CIpxnhD
Z2zWt44RBz21rbN8f3ICfb1lIezxoxtirhEWylOsKR7rg8sbucPPAGszu7nOPz6R
NzIfqRxAWfhK10j89RDshNkzsgajaE3hrsUh30rfOaup1EDIhSz36NAuqCixnTbo
3S/HaiMOpMNlVgpZ1/3YjDI0r+YA7tj7f5Uop5I3/M44qLoyaAk=
=cC4H
-----END PGP SIGNATURE-----

Hi!

This one caught my eye, as using DEB_TARGET_* is usually suspect.
Is this really intended for Canadian cross-compiler support? Or should it
be instead DEB_HOST_ARCH_BITS?

While at it, this also seemed suspect. Is this really for the build
system instead of the host one?

Thanks,
Guillem

Hi!

I actually thought about that one before doing it, and I did not see a
difference between host and target in that case so that's rather random.

Good catch.

That was me modifying an old option instead of writing it from scratch,
and not looking closely what it was.

cu
Adrian