On Sun, Jun 12, 2022 at 5:38 PM Drew Parsons <dparsons@debian.org> wrote:

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental, https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

It previously built fine, but the latest version 1:0.4.1 has evidently
grown large enough to break on mipsel.

mip64el builds successfully, as we might expect. But it's not simply a
32-bit issue in the sense that i386, armel, armhf are all still building successfully.

Build logs can be found at https://buildd.debian.org/status/logs.php?pkg=fenics-dolfinx&arch=mipsel

In the build for 1:0.4.1-1exp1 we see:

[ 83%] Building CXX object CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_TIMER_DYN_LINK -DDOLFINX_VERSION=\"0.4.1\" -DHAS_PTSCOTCH
-DHAS_SLEPC -D_FILE_OFFSET_BITS=64 -Dcpp_EXPORTS -I/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/python3/dist-packages/petsc4py/include
-I/usr/lib/python3/dist-packages/mpi4py/include -isystem /usr/include/python3.9 -isystem /usr/lib/python3/dist-packages/pybind11/include -isystem /usr/lib/python3/dist-packages/ffcx/codegeneration -isystem /usr/lib/mipsel-linux-gnu/openmpi/include -isystem /usr/lib/mipsel-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/include -isystem /usr/include/hdf5/openmpi -isystem /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/include -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /<<PKGBUILDDIR>>/debian/tmp-complex/usr/include -DVERSION_INFO=\"0.4.1\"
-O3 -DNDEBUG -fPIC -fvisibility=hidden -Wall -Werror -pedantic -flto -fno-fat-lto-objects -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17
-MD -MT CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o -MF CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o.d -o CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o -c /<<PKGBUILDDIR>>/python/dolfinx/wrappers/nls.cpp
[ 91%] Building CXX object CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o
/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK -DBOOST_TIMER_DYN_LINK -DDOLFINX_VERSION=\"0.4.1\" -DHAS_PTSCOTCH
-DHAS_SLEPC -D_FILE_OFFSET_BITS=64 -Dcpp_EXPORTS -I/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/python3/dist-packages/petsc4py/include
-I/usr/lib/python3/dist-packages/mpi4py/include -isystem /usr/include/python3.9 -isystem /usr/lib/python3/dist-packages/pybind11/include -isystem /usr/lib/python3/dist-packages/ffcx/codegeneration -isystem /usr/lib/mipsel-linux-gnu/openmpi/include -isystem /usr/lib/mipsel-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/include -isystem /usr/include/hdf5/openmpi -isystem /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/include -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /<<PKGBUILDDIR>>/debian/tmp-complex/usr/include -DVERSION_INFO=\"0.4.1\"
-O3 -DNDEBUG -fPIC -fvisibility=hidden -Wall -Werror -pedantic -flto -fno-fat-lto-objects -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17
-MD -MT CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o -MF CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o.d -o CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o -c /<<PKGBUILDDIR>>/python/dolfinx/wrappers/refinement.cpp

cc1plus: out of memory allocating 17707045 bytes after a total of
42041344 bytes

In the first instance I tried switching off LTO, adding the cmake configuration "set(CMAKE_INTERPROCEDURAL_OPTIMIZATION FALSE)" which deactivates -flto.
But it didn't fix the problem. The corresponding log for 1:0.4.1-1exp2
shows much the same problem,

virtual memory exhausted: Cannot allocate memory

I then tried building on the porterbox eller.debian.org, reducing optimization from -O3 to -O2, but that gave the same result.

Finally I tried with no optimizations at all (-O0) via cmake option add_compile_options(-O0). This did allow the object files to build, but
then linking failed with relocation truncated:

[100%] Linking CXX shared module ../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so /usr/bin/cmake -E cmake_link_script CMakeFiles/cpp.dir/link.txt
--verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/home/dparsons/dolfinx/fenics-dolfinx=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr
/include -DVERSION_INFO=\"0.4.1\" -O3 -DNDEBUG -pthread -Wl,-z,relro
-shared -o ../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so CMakeFiles/cpp.dir/dolfinx/wrappers/dolfinx.cpp.o CMakeFiles/cp p.dir/dolfinx/wrappers/common.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/geometry.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/graph.cpp.o CMakeFiles/cpp.dir/dolfinx/wra
ppers/io.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/la.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/log.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/mesh.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o CMakeFiles/c pp.dir/dolfinx/wrappers/refinement.cpp.o -Wl,-rpath,/home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr/lib/mipsel-linux-gnu:/usr/lib/mipsel-linux-gnu/openmpi/lib:/usr/lib/mipsel-linux-gnu/hdf5/openmpi
:/usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/lib:/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib
/home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr/lib/mipsel-linux-gnu/libdolfinx_com
plex.so.0.4.1 /usr/lib/mipsel-linux-gnu/libbasix.so.0.4.2 /usr/lib/mipsel-linux-gnu/libboost_timer.so.1.74.0 /usr/lib/mipsel-linux-gnu/libboost_chrono.so.1.74.0 /usr/lib/mipsel-linux-gnu/openmpi/lib/libmpi_cxx.so /usr/lib/mipsel-linux-gnu/openmpi/lib/libmpi.so /usr/lib/mipsel-linux-gnu/hdf5/openmpi/libhdf5.so /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/lib/libslepc_complex.so /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/libpetsc_complex.so CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `_PyObject_TypeCheck':
/usr/include/python3.10/object.h:247:(.text+0xa0): relocation truncated
to fit: R_MIPS_CALL16 against `PyType_IsSubtype' CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `_Py_DECREF': /usr/include/python3.10/object.h:500:(.text+0x174): relocation truncated
to fit: R_MIPS_CALL16 against `_Py_Dealloc' CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `__Pyx_ImportFunction(_object*, char const*, void (**)(), char const*)': /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:111:(.text+0x46c):
relocation truncated to fit: R_MIPS_CALL16 against
`PyObject_GetAttrString' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:114:(.text+0x498):
relocation truncated to fit: R_MIPS_CALL16 against
`PyDict_GetItemString' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4bc):
relocation truncated to fit: R_MIPS_GOT16 against `PyExc_ImportError' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4c8):
relocation truncated to fit: R_MIPS_CALL16 against `PyModule_GetName' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4f0):
relocation truncated to fit: R_MIPS_CALL16 against `PyErr_Format' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:122:(.text+0x514):
relocation truncated to fit: R_MIPS_CALL16 against `PyCapsule_IsValid' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x538):
relocation truncated to fit: R_MIPS_GOT16 against `PyExc_TypeError' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x544):
relocation truncated to fit: R_MIPS_CALL16 against `PyModule_GetName' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x560):
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
gmake[4]: *** [CMakeFiles/cpp.dir/build.make:266: ../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so]
Error 1

At this point I'm out of clues. What do you recommend?

I used to see something similar when building Crypto++ on resource
constrained dev-boards without swap files, like a BeagleBoard. cc1plus
used to crash all the time when certain source files were built,
especially ones that included a lot of header files. The symptom was
the same as:

cc1plus: out of memory allocating 17707045
bytes after a total of 42041344 bytes

Drop back to 1 make job. Don't use `make -j N`. Instead, just use
`make` or `make -j 1`.

Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental, https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

It previously built fine, but the latest version 1:0.4.1 has evidently
grown large enough to break on mipsel.

mip64el builds successfully, as we might expect. But it's not simply a
32-bit issue in the sense that i386, armel, armhf are all still building successfully.

Build logs can be found at https://buildd.debian.org/status/logs.php?pkg=fenics-dolfinx&arch=mipsel

In the build for 1:0.4.1-1exp1 we see:

[ 83%] Building CXX object CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o /usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK
-DBOOST_TIMER_DYN_LINK -DDOLFINX_VERSION=\"0.4.1\" -DHAS_PTSCOTCH
-DHAS_SLEPC -D_FILE_OFFSET_BITS=64 -Dcpp_EXPORTS -I/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/python3/dist-packages/petsc4py/include
-I/usr/lib/python3/dist-packages/mpi4py/include -isystem
/usr/include/python3.9 -isystem
/usr/lib/python3/dist-packages/pybind11/include -isystem /usr/lib/python3/dist-packages/ffcx/codegeneration -isystem /usr/lib/mipsel-linux-gnu/openmpi/include -isystem /usr/lib/mipsel-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/include -isystem /usr/include/hdf5/openmpi -isystem /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/include -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /<<PKGBUILDDIR>>/debian/tmp-complex/usr/include -DVERSION_INFO=\"0.4.1\"
-O3 -DNDEBUG -fPIC -fvisibility=hidden -Wall -Werror -pedantic -flto -fno-fat-lto-objects -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17
-MD -MT CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o -MF CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o.d -o CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o -c /<<PKGBUILDDIR>>/python/dolfinx/wrappers/nls.cpp
[ 91%] Building CXX object
CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o
/usr/bin/c++ -DBOOST_ALL_NO_LIB -DBOOST_CHRONO_DYN_LINK
-DBOOST_TIMER_DYN_LINK -DDOLFINX_VERSION=\"0.4.1\" -DHAS_PTSCOTCH
-DHAS_SLEPC -D_FILE_OFFSET_BITS=64 -Dcpp_EXPORTS -I/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/python3/dist-packages/petsc4py/include
-I/usr/lib/python3/dist-packages/mpi4py/include -isystem
/usr/include/python3.9 -isystem
/usr/lib/python3/dist-packages/pybind11/include -isystem /usr/lib/python3/dist-packages/ffcx/codegeneration -isystem /usr/lib/mipsel-linux-gnu/openmpi/include -isystem /usr/lib/mipsel-linux-gnu/openmpi/include/openmpi -isystem /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/include -isystem /usr/include/hdf5/openmpi -isystem /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/include -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /<<PKGBUILDDIR>>/debian/tmp-complex/usr/include -DVERSION_INFO=\"0.4.1\"
-O3 -DNDEBUG -fPIC -fvisibility=hidden -Wall -Werror -pedantic -flto -fno-fat-lto-objects -pthread -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++17
-MD -MT CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o -MF CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o.d -o CMakeFiles/cpp.dir/dolfinx/wrappers/refinement.cpp.o -c /<<PKGBUILDDIR>>/python/dolfinx/wrappers/refinement.cpp

cc1plus: out of memory allocating 17707045 bytes after a total of
42041344 bytes


In the first instance I tried switching off LTO, adding the cmake
configuration "set(CMAKE_INTERPROCEDURAL_OPTIMIZATION FALSE)" which
deactivates -flto.
But it didn't fix the problem. The corresponding log for 1:0.4.1-1exp2
shows much the same problem,

virtual memory exhausted: Cannot allocate memory

I then tried building on the porterbox eller.debian.org, reducing
optimization from -O3 to -O2, but that gave the same result.

Finally I tried with no optimizations at all (-O0) via cmake option add_compile_options(-O0). This did allow the object files to build, but
then linking failed with relocation truncated:

[100%] Linking CXX shared module ../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so /usr/bin/cmake -E cmake_link_script CMakeFiles/cpp.dir/link.txt
--verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/home/dparsons/dolfinx/fenics-dolfinx=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr
/include -DVERSION_INFO=\"0.4.1\" -O3 -DNDEBUG -pthread -Wl,-z,relro
-shared -o
../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so CMakeFiles/cpp.dir/dolfinx/wrappers/dolfinx.cpp.o CMakeFiles/cp p.dir/dolfinx/wrappers/common.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/geometry.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/graph.cpp.o
CMakeFiles/cpp.dir/dolfinx/wra
ppers/io.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/la.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/log.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/mesh.cpp.o CMakeFiles/cpp.dir/dolfinx/wrappers/nls.cpp.o CMakeFiles/c pp.dir/dolfinx/wrappers/refinement.cpp.o -Wl,-rpath,/home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr/lib/mipsel-linux-gnu:/usr/lib/mipsel-linux-gnu/openmpi/lib:/usr/lib/mipsel-linux-gnu/hdf5/openmpi
:/usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/lib:/usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib
/home/dparsons/dolfinx/fenics-dolfinx/debian/tmp-complex/usr/lib/mipsel-linux-gnu/libdolfinx_com
plex.so.0.4.1 /usr/lib/mipsel-linux-gnu/libbasix.so.0.4.2 /usr/lib/mipsel-linux-gnu/libboost_timer.so.1.74.0 /usr/lib/mipsel-linux-gnu/libboost_chrono.so.1.74.0 /usr/lib/mipsel-linux-gnu/openmpi/lib/libmpi_cxx.so /usr/lib/mipsel-linux-gnu/openmpi/lib/libmpi.so /usr/lib/mipsel-linux-gnu/hdf5/openmpi/libhdf5.so /usr/lib/slepcdir/slepc3.16/mipsel-linux-gnu-complex/lib/libslepc_complex.so /usr/lib/petscdir/petsc3.16/mipsel-linux-gnu-complex/lib/libpetsc_complex.so CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `_PyObject_TypeCheck':
/usr/include/python3.10/object.h:247:(.text+0xa0): relocation truncated
to fit: R_MIPS_CALL16 against `PyType_IsSubtype' CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `_Py_DECREF': /usr/include/python3.10/object.h:500:(.text+0x174): relocation truncated
to fit: R_MIPS_CALL16 against `_Py_Dealloc' CMakeFiles/cpp.dir/dolfinx/wrappers/fem.cpp.o: in function `__Pyx_ImportFunction(_object*, char const*, void (**)(), char const*)': /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:111:(.text+0x46c):
relocation truncated to fit: R_MIPS_CALL16 against
`PyObject_GetAttrString' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:114:(.text+0x498):
relocation truncated to fit: R_MIPS_CALL16 against
`PyDict_GetItemString' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4bc):
relocation truncated to fit: R_MIPS_GOT16 against `PyExc_ImportError' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4c8):
relocation truncated to fit: R_MIPS_CALL16 against `PyModule_GetName' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:116:(.text+0x4f0):
relocation truncated to fit: R_MIPS_CALL16 against `PyErr_Format' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:122:(.text+0x514):
relocation truncated to fit: R_MIPS_CALL16 against `PyCapsule_IsValid' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x538):
relocation truncated to fit: R_MIPS_GOT16 against `PyExc_TypeError' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x544):
relocation truncated to fit: R_MIPS_CALL16 against `PyModule_GetName' /usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.MPI_api.h:123:(.text+0x560):
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status
gmake[4]: *** [CMakeFiles/cpp.dir/build.make:266: ../lib.linux-mips-3.10/dolfinx/cpp.cpython-310-mipsel-linux-gnu.so]
Error 1


At this point I'm out of clues. What do you recommend?

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jun 12, 2022 at 11:38 PM Drew Parsons <dparsons@debian.org> wrote:

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental, https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

It previously built fine, but the latest version 1:0.4.1 has evidently
grown large enough to break on mipsel.

Here is what I used in openvdb:

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L28-32

# Disable optimization on mips* because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips mipsel sh4)) CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-06-13 00:02, Jeffrey Walton wrote:

On Sun, Jun 12, 2022 at 5:38 PM Drew Parsons <dparsons@debian.org>
wrote:

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental,
https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

...

I used to see something similar when building Crypto++ on resource constrained dev-boards without swap files, like a BeagleBoard. cc1plus
used to crash all the time when certain source files were built,
especially ones that included a lot of header files. The symptom was
the same as:

cc1plus: out of memory allocating 17707045
bytes after a total of 42041344 bytes

Drop back to 1 make job. Don't use `make -j N`. Instead, just use
`make` or `make -j 1`.

It's a good thought, but unfortunately it didn't help.

I applied it as "DEB_BUILD_OPTIONS = parallel=1" in debian/rules so dh_auto_build proceeds with "make -j1 "INSTALL=install
--strip-program=true" VERBOSE=1"

Applied on top of the fenics-dolfinx 1:0.4.1-1exp2 build configuration
(with lto deactivated), it still gives

c1plus: out of memory allocating 17707031 bytes after a total of
41906176 bytes

when compiling dolfinx/wrappers/refinement.cpp.o.

Running make -j1 with all optimisation switched off (-O0) gives the same linking error I reported before: linking the python extension cpp.cpython-310-mipsel-linux-gnu.so still gets the error "relocation
truncated to fit".

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons <dparsons@debian.org> wrote:

On 2022-06-13 10:01, Mathieu Malaterre wrote:

On Sun, Jun 12, 2022 at 11:38 PM Drew Parsons <dparsons@debian.org>
wrote:

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental,
https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

It previously built fine, but the latest version 1:0.4.1 has evidently
grown large enough to break on mipsel.

Here is what I used in openvdb:

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L28-32

# Disable optimization on mips* because the compiler is running out of memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips mipsel sh4)) CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif

Thanks Mathieu, I'll try that and see if gc-min-expand helps.

But I'm starting to suspect I have two separate problems. First I need
to compile the object files, and running out of memory is the problem
there. Fixed by reducing -O (ggc-min-expand might help also).

But after that, there's the problem linking, with "relocation
truncated". Am I right to think that's not an issue of available RAM as such, but rather it means the address space required by object files has started to exceed 32-bits?

I'll upload a fenics-dolfinx 1:0.4.1-1exp3 to get the "relocation
truncated" error on the buildlog record.

How would we usually manage "relocation truncated" linking errors?

I've never used it myself. But it appears to be the option "-mxgot":

* https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-06-13 10:01, Mathieu Malaterre wrote:

On Sun, Jun 12, 2022 at 11:38 PM Drew Parsons <dparsons@debian.org>
wrote:

Hi MIPS porters, I need helping with the build of fenics-dolfinx on
mipsel from experimental,
https://salsa.debian.org/science-team/fenics/fenics-dolfinx/-/tree/experimental

It previously built fine, but the latest version 1:0.4.1 has evidently
grown large enough to break on mipsel.

Here is what I used in openvdb:

https://salsa.debian.org/multimedia-team/openvdb/-/blob/master/debian/rules#L28-32

# Disable optimization on mips* because the compiler is running out of
memory
# see #847752 / #879636
ifneq (,$(filter $(DEB_BUILD_ARCH_CPU), mips mipsel sh4)) CXXFLAGS:=$(filter-out -O2,$(CXXFLAGS)) --param ggc-min-expand=10 -O1
endif

Thanks Mathieu, I'll try that and see if gc-min-expand helps.

But I'm starting to suspect I have two separate problems. First I need
to compile the object files, and running out of memory is the problem
there. Fixed by reducing -O (ggc-min-expand might help also).

But after that, there's the problem linking, with "relocation
truncated". Am I right to think that's not an issue of available RAM as
such, but rather it means the address space required by object files has started to exceed 32-bits?

I'll upload a fenics-dolfinx 1:0.4.1-1exp3 to get the "relocation
truncated" error on the buildlog record.

How would we usually manage "relocation truncated" linking errors?

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jun 13, 2022 at 4:44 AM Drew Parsons <dparsons@debian.org> wrote:

...
But I'm starting to suspect I have two separate problems. First I need
to compile the object files, and running out of memory is the problem
there. Fixed by reducing -O (ggc-min-expand might help also).

But after that, there's the problem linking, with "relocation
truncated". Am I right to think that's not an issue of available RAM as such, but rather it means the address space required by object files has started to exceed 32-bits?

I would see this with Crypto++ when cc1plus crashed. The object file
was not fully written, and the object file for the source file was
corrupt.

In this case, delete the object file in question, and then build
again. That is, if the compiler crashed compiling foo.cc, then delete
foo.o and then run make again.

Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-06-13 10:52, Mathieu Malaterre wrote:

On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons <dparsons@debian.org>
wrote:

How would we usually manage "relocation truncated" linking errors?

I've never used it myself. But it appears to be the option "-mxgot":

* https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

That's a good tip. -mxgot seems to be a kind of MIPS counterpart to the
x86 flag -mcmodel=medium, which was suggested at https://stackoverflow.com/a/35111263/12401525 for resolving relocation
errors.

Compiling with -mxgot (and deleting/rebuilding fem.cpp.o as Jeffrey
suggested) my linking got past the general relocation error that it was
giving before. It then gave a relocation error related to specific xt (xtensor) functions, but that's enough of a clue to work with.

xtensor is a header-only library, to successfully build its tests on
mipsel we had to compile with -Os -g0. If I do that with dolfinx on
mipsel then it finally links the python extension successfully.

Not certain if I need to use both -mxgot and -Os -g0, but I can test the various build permutations now.

Thanks for your help, MIPS experts.

Drew

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jun 13, 2022 at 1:29 PM Drew Parsons <dparsons@debian.org> wrote:

On 2022-06-13 10:52, Mathieu Malaterre wrote:

On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons <dparsons@debian.org>
wrote:

How would we usually manage "relocation truncated" linking errors?

I've never used it myself. But it appears to be the option "-mxgot":

* https://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html

That's a good tip. -mxgot seems to be a kind of MIPS counterpart to the
x86 flag -mcmodel=medium, which was suggested at https://stackoverflow.com/a/35111263/12401525 for resolving relocation errors.

Compiling with -mxgot (and deleting/rebuilding fem.cpp.o as Jeffrey suggested) my linking got past the general relocation error that it was giving before. It then gave a relocation error related to specific xt (xtensor) functions, but that's enough of a clue to work with.

xtensor is a header-only library, to successfully build its tests on
mipsel we had to compile with -Os -g0. If I do that with dolfinx on
mipsel then it finally links the python extension successfully.

Not certain if I need to use both -mxgot and -Os -g0, but I can test the various build permutations now.

Thanks for your help, MIPS experts.

Sorry to dig up an old thread.

GNU Make's .DELETE_ON_ERROR may help in the future. Also see https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
and https://www.gnu.org/software/make/manual/html_node/Errors.html .

Especially the part:

... if the recipe fails after beginning to change the file.
make will do this if .DELETE_ON_ERROR appears
as a target. This is almost always what you want
make to do, but it is not historical practice; so for
compatibility, you must explicitly request it.

Jeff

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)