Re: mipsel out-of-memory building dolfinx 0.4.0
On Mon, Jun 13, 2022 at 1:29 PM Drew Parsons <email@example.com> wrote:
> On 2022-06-13 10:52, Mathieu Malaterre wrote:
> > On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons <firstname.lastname@example.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
> 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
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.