On 2020-08-25 08:31, YunQiang Su wrote:
Drew Parsons <dparsons@debian.org> 于2020年8月25日周二 上午12:29写道：On 2020-08-22 18:52, Drew Parsons wrote: > On 2020-08-19 23:08, Drew Parsons wrote: >> Can anyone help with the mips64el build of dolfin? It's failing when >> building python extensions: >> >> /usr/bin/ld: >> /tmp/cpp.cpython-38-mips64el-linux-gnuabi64.so.AnBotY.ltrans29.ltrans.o: >> .symtab local symbol at index 482 (>= sh_info of 99) >> /usr/bin/ld:
...
If the problem is not a full /tmp partition, could the error be caused by some inconsistent library caught badly in the middle of the gcc-10 transition? How to know?Maybe. Let's have a check. I think that we can have a try to build the previous version. I will do it.
On irc, Jessica Clarke [jrtc27] suggested LTO (-flto) might be the problem.
Sure enough, dolfin does build successfully on mip64el if I apply -fno-lto
Specifically, the -flto was coming from pybind11, not from the dolfin configuration itself. It's the same pybind11 version though (2.5.0), so not still clear why the mips64el dolfin build started failing so suddenly.
The last successful dolfin build did use -flto. The timing of the failures roughly coincides with gcc-10 becoming default. Does it mean gcc-10 is doing something different with LTO, that's caused a regression on mips64el?
If so, then the problem might show up on mip64el in other packages that use pybind11.
Not sure if -flto or pybind11 needs deeper investigation on mip64el, but as a workaround I'll configure dolfin to instruct pybind11 to use -fno-lto.
Drew