Re: dolfin FTBFS on mips64el: ld error adding symbols: bad value

On 2020-08-25 08:31, YunQiang Su wrote:
> Drew Parsons <[email protected]> 于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