Simon McVittie <s...@debian.org> 于2019年7月18日周四 上午2:03写道： > > On Wed, 17 Jul 2019 at 12:18:14 +0100, Simon McVittie wrote: > > It looks like the culprit might be commit > > d04b9c371d277fa45ba20ad83642e57af50381e7: > > https://gitlab.gnome.org/GNOME/glib/commit/d04b9c371d277fa45ba20ad83642e57af50381e7 > > Is that objcopy invocation wrong for mips64el? Does mips64el objcopy perhaps > > default to a different ABI? > > Looks like plain objcopy produces MIPS-I objects, whereas invoking it > in the normal way via the compiler frontend produces MIPS64r2 objects: > > (sid_mips64el-dchroot)smcv@eller ~/glib % file > debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o > debian/build/deb/gio/tests/bcb7ac7@@actions@exe/actions.c.o: ELF 64-bit LSB > relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), with debug_info, not stripped > (sid_mips64el-dchroot)smcv@eller ~/glib % file > debian/build/deb/gio/tests/test_resources2.o > debian/build/deb/gio/tests/test_resources2.o: ELF 64-bit LSB relocatable, > MIPS, MIPS-I version 1 (SYSV), not stripped >
I guess you are right, objcopy doesn't alter the object file correctly. We need to patch it. > Regards, > smcv > -- YunQiang Su
