Hi. I'm looking for a suggestion to fix a problem.
I uploaded a package, and it cleared NEW a few days ago. I now see that it fails to build on most 32-bit arches becaues the compiler runs out of memory. Logs: https://buildd.debian.org/status/package.php?p=gtsam Arbitrary 32-bit log (armhf): https://buildd.debian.org/status/fetch.php?pkg=gtsam&arch=armhf&ver=4.2%7E9%2Bdfsg-2&stamp=1691926953&raw=0 I thought it maybe is due to doing too many things in parallel, but building with -j1 doesn't fix it. I have boiled down the problem to compiling a single source file. Unsuprisingly, this is a big generated C++ source file used to define the Python interface. I can reproduce this with a single compile command on abel.d.o (the armhf porterbox): apt source gtsam cd gtsam-4.2~9+dfsg PYTHONPATH=wrap \ python3 "wrap/scripts/pybind_wrap.py" \ --src "gtsam/geometry/geometry.i" \ --out geometry.cpp \ --module_name gtsam \ --top_module_namespaces gtsam \ --ignore gtsam::Point2 gtsam::Point3 gtsam::ISAM2ThresholdMapValue gtsam::FactorIndices gtsam::FactorIndexSet gtsam::IndexPairSetMap gtsam::IndexPairVector gtsam::BetweenFactorPose2s gtsam::BetweenFactorPose3s gtsam::Point2Vector gtsam::Point2Pairs gtsam::Point3Pairs gtsam::Pose3Pairs gtsam::Pose3Vector gtsam::Rot3Vector gtsam::KeyVector gtsam::BinaryMeasurementsPoint3 gtsam::BinaryMeasurementsUnit3 gtsam::BinaryMeasurementsRot3 gtsam::DiscreteKey gtsam::KeyPairDoubleMap gtsam::gtsfm::MatchIndicesMap gtsam::gtsfm::KeypointsVector gtsam::gtsfm::SfmTrack2dVector \ --template "python/gtsam/gtsam.tpl" \ --is_submodule \ --use-boost < cmake/dllexport.h.in sed \ ' s/#cmakedefine/#define/g; s/@library_name@/GTSAM/g; ' > gtsam/dllexport.h < gtsam/config.h.in sed \ ' s/#cmakedefine/#define/g; s/@GTSAM_VERSION_MAJOR@/4/g; s/@GTSAM_VERSION_MINOR@/2/g; s/@GTSAM_VERSION_PATCH@/0/g; s/@GTSAM_VERSION_NUMERIC@/40200/g; s/@GTSAM_VERSION_STRING@/4.2a9/g; s/@GTSAM_EIGEN_VERSION_WORLD@/3/g; s/@GTSAM_EIGEN_VERSION_MAJOR@/4/g; s/.*define .*_USE.*_MKL.*//g; s/.*define GTSAM_EIGEN_VERSION_MINOR.*//g; s/.*define GTSAM_ALLOCATOR_BOOSTPOOL.*//g; s/.*define GTSAM_ALLOCATOR_STL.*//g; s/.*define GTSAM_SLOW_BUT_CORRECT_BETWEENFACTOR.*//g; s/.*define GTSAM_USE_QUATERNIONS.*//g; ' > gtsam/config.h /usr/bin/c++ \ -DBOOST_ALL_NO_LIB \ -DBOOST_ATOMIC_DYN_LINK \ -DBOOST_CHRONO_DYN_LINK \ -DBOOST_DATE_TIME_DYN_LINK \ -DBOOST_FILESYSTEM_DYN_LINK \ -DBOOST_PROGRAM_OPTIONS_DYN_LINK \ -DBOOST_REGEX_DYN_LINK \ -DBOOST_SERIALIZATION_DYN_LINK \ -DBOOST_SYSTEM_DYN_LINK \ -DBOOST_THREAD_DYN_LINK \ -DBOOST_TIMER_DYN_LINK \ -Dgtsam_py_EXPORTS \ -I"." \ -I"CppUnitLite" \ -isystem /usr/include/python3.11 \ -isystem /usr/include/eigen3 \ -g \ -O2 \ -fstack-protector-strong \ -Wformat \ -Werror=format-security \ -Wdate-time \ -D_FORTIFY_SOURCE=2 \ -g \ -DNDEBUG \ -fPIC \ -fvisibility=hidden \ -o /tmp/tst.o \ -c geometry.cpp On abel.d.o this crunches for a while, and then says cc1plus: out of memory allocating 152612 bytes after a total of 59252736 bytes I will report this upstream, but I don't yet know what to tell them. Any suggestions here for debian and/or for upstream? If I was upstream, I'd do a lot of this differently, but I'm not going to ask them to majorly rearchitect their thing. Thanks.