boost 1.89.0 #233031
Merged
boost 1.89.0 #233031
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cho-m
added
in progress
github-actions
bot
added
automerge-skip
This was referenced Aug 10, 2025
cho-m
force-pushed
the
bump-boost-1.89.0
branch
from
299e402 to
a8fdc98
Compare
This was referenced Aug 12, 2025
cho-m
force-pushed
the
bump-boost-1.89.0
branch
from
a8fdc98 to
2c0c1ce
Compare
cho-m
changed the title
cho-m
commented
Aug 14, 2025
cho-m
commented
Aug 14, 2025
|
Waiting on abseil / protobuf PR before pushing changes for official 1.89.0 release |
cho-m
force-pushed
the
bump-boost-1.89.0
branch
from
2c0c1ce to
ce146d0
Compare
github-actions
bot
added
the
CI-published-bottle-commits
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
chenrui333
approved these changes
Aug 18, 2025
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Aug 31, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Aug 31, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Aug 31, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Aug 31, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Sep 1, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Sep 1, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to robertkirkman/termux-packages
that referenced
this pull request
Sep 2, 2025
- Progress on termux#23492 - Dependency of termux#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
robertkirkman
added a commit
to termux/termux-packages
that referenced
this pull request
Sep 2, 2025
- Progress on #23492 - Dependency of #25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
termux-pacman-bot
added a commit
to termux-pacman/termux-packages
that referenced
this pull request
Sep 2, 2025
- Progress on termux/termux-packages#23492 - Dependency of termux/termux-packages#25826 - In order to rebuild all reverse dependencies successfully, also includes some fixes for builds of packages that currently fail to build with CMake 4, which are either the commonly-used `-DCMAKE_POLICY_VERSION_MINIMUM=3.5` argument, or are patches named to indicate their purpose - All patches with attribution headers are cherry-picked from respective upstream PRs or commits - All patches without attribution headers are written from scratch by me to solve errors that are either Termux-specific or are not yet fixed anywhere in upstream Some notes about unique patches: - Very big thanks to cho-m, who almost single-handedly brought boost 1.89 to `libc++`-based UNIX-like operating systems with their work on boost 1.89 for MacOS in Homebrew/homebrew-core#233031. Many cherry-picked patches originated from them. - I chose to write my own patch for `ncmpcpp` for boost 1.89 rather then exactly copy the example of cho-m, even though my method involves more lines of code, because **I decided that I would like to be notified, through the patch failing to apply, when upstream `ncmpcpp` has added official support for boost 1.89**, indicating that the downstream change can then be removed without me having to remember it, which cho-m's example unfortunately wouldn't do. - For some reason, building `openfoam` with boost 1.89 instead of boost 1.87 causes it to attempt to link to `libgmp.so` in a nonexistent folder `/data/data/com.termux/files/usr/lib64`, instead of `/data/data/com.termux/files/usr/lib` - It's unclear how exactly boost 1.89 draws out this error, but it can also be seen that the origin of the "lib64" instance is within openfoam, and Termux does not use any "lib64" folder, so it should be patched out from `openfoam` (which resolves the error) ``` -L/data/data/com.termux/files/usr/lib64 -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib -L/home/builder/.termux-build/openfoam/src/ThirdParty/platforms/linuxARM64Clang/boost-system/lib64 -lmpfr -lgmp -lfileFormats -lsurfMesh -lmeshTools -ldecompose -ldynamicMesh -lsnappyHexMesh -o /home/builder/.termux-build/openfoam/src/platforms/linuxARM64ClangDPInt32Opt/lib/libconformalVoronoiMesh.so ld.lld: error: unable to find library -lmpfr ``` - `ravencoin` and `mkvtoolnix` use `autoreconf -fi` during their `build.sh` files, but unfortunately, in the Ubuntu 24.04 cross-builder Docker image, there is a package installed in Ubuntu `autoconf-archive` version 20220903-3, which contains a file `/usr/share/aclocal/ax_boost_system.m4`, and this file is unfortunately propagated into the build systems of `ravencoin` and `mkvtoolnix` by `autoreconf -fi` and "pollutes" them with "awareness" that they would not otherwise have of the `Boost::System` shared library that no longer exists in boost 1.89, so temporary changes to `TERMUX_PKG_EXTRA_CONFIGURE_ARGS` are required, which should be removed the next time the Ubuntu cross-builder image is bumped, since after that happens, they will no longer be necessary. - Copy and paste fix for building `abiword` with `libc++` 19+ (NDK r28c) from FreeBSD: freebsd/freebsd-ports@e6daa21 - Fix prefix pollution `libjxl`->`telegram-desktop` - (i.e. the command `scripts/run-docker.sh ./build-package.sh -I -f libjxl telegram-desktop`) - For clarity, the edits to `packages/libjxl/fix-pkgconfig-file.patch` are primarily implementing this fix by removing the invalid path `/data/data/com.termux/files/usr//data/data/com.termux/files/usr/include` from the command `pkg-config --cflags libjxl`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pre-release testing to try to catch issues prior to official release planned for Aug 13.
Major impacting change is Boost System becoming header-only - boostorg/system#132
Workaround in PR but not reported upstream:
pinocchio- Boost.System issuecollada-dom- just adding workaround as upstream seems dead. My previous Boost issue for 1.85.0 is still open and no activity in 6 years.Fix/workaround in PR and contacted upstream:
cryfs- Fix build with Boost 1.89.0 cryfs/cryfs#500gnuradio- cmake: fix build with Boost 1.89.0 gnuradio/gnuradio#7904osrm-backend- Fix build with Boost 1.89.0 Project-OSRM/osrm-backend#7220proxygen- Fix build with Boost 1.89.0 facebook/proxygen#570libphonenumber- Fix build with Boost 1.89.0 google/libphonenumber#3903apngasm- Fix build with Boost 1.89.0 apngasm/apngasm#111mvfst- Fix build with Boost 1.89.0 facebook/mvfst#405innoextract- CMake: Fix build with Boost 1.89.0 dscharrer/innoextract#199mapcrafter- Fix build with Boost 1.89.0 mapcrafter/mapcrafter#395standardese- Fix build with Boost 1.89.0 standardese/standardese#249manticoresearch- Build fails with upcoming Boost 1.89.0 (with Galera) manticoresoftware/manticoresearch#3673dwarfs- Build fails with upcoming Boost 1.89.0 facebook/folly#2489folly- Build fails with upcoming Boost 1.89.0 facebook/folly#2489c10t- Build fails with upcoming Boost 1.89.0 udoprog/c10t#315ncmpcpp- [BUG] Build fails with upcoming Boost 1.89.0 ncmpcpp/ncmpcpp#633prjtrellis- Build fails with upcoming Boost 1.89.0 YosysHQ/prjtrellis#251uhd- Build fails with upcoming Boost 1.89.0 EttusResearch/uhd#869coal- Build fails with upcoming Boost 1.89.0 coal-library/coal#743ompl- Build fails with upcoming Boost 1.89.0 ompl/ompl#1305pdnsrec- Build fails with upcoming Boost 1.89.0 PowerDNS/pdns#15972sfcgal- https://gitlab.com/sfcgal/SFCGAL/-/issues/306Fixed upstream, backported to PR:
colmap- Fix build with Boost 1.89.0 colmap/colmap#3553fastnetmon- Fix build with Boost 1.89.0 pavel-odintsov/fastnetmon#1038i2pd- Build fails with upcoming Boost 1.89.0 PurpleI2P/i2pd#2218 - Boost.Asio changeerror: no type named 'deadline_timer' in namespace 'boost::asio'ledger- Fix build with Boost 1.89.0 ledger/ledger#2430lgogdownloader- https://github.com/Sude-/lgogdownloader/pull/296monero(linux) - epee: include math header for upcoming Boost 1.89 monero-project/monero#10036pcl- PointCloudLibrary/pcl@564074brdkit- Fix build with Boost 1.89.0 rdkit/rdkit#8694simple-amqp-client- Fix build with Boost 1.89.0 alanxz/SimpleAmqpClient#356solidity- Remove the hard dependency onboost::systemcompatibility library to fix builds with Boost 1.89.0 argotorg/solidity#16163votca- Fix build with Boost 1.89.0 votca/votca#1183Fixed upstream, workaround in PR:
logstalgia- Build fails with upcoming Boost 1.89.0 acaudwell/Logstalgia#40gource- Build fails with upcoming Boost 1.89.0 acaudwell/Gource#348avro-cpp- upstream dropped non-test Boost usage (apache/avro@1144cb7) so using workaround until next releasemkvtoolnix- https://codeberg.org/mbunkus/mkvtoolnix/issues/6143 - fixed but requires autoreconf so using workaround insteadsupertux- upstream dropped Boost (SuperTux/supertux@5333ceb) but not in release yet so using workaroundCI failures (needs macOS/Xcode upgrade for Sequoia runners):
cpprestsdk(15-arm64) - Xcode 16.3 failure - povray cpprestsdk: apply FreeBSD patches for Xcode 16.3 #233303povray(15-arm64) - Xcode 16.3 failure - povray cpprestsdk: apply FreeBSD patches for Xcode 16.3 #233303