Compiler runs out of memory when building a package
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.
Reply to: