On Mon, Jun 13, 2022 at 1:29 PM Drew Parsons <[email protected]> wrote: > > On 2022-06-13 10:52, Mathieu Malaterre wrote: > > On Mon, Jun 13, 2022 at 10:44 AM Drew Parsons <[email protected]> > > 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
