I think I know what's happening. In 0.12.12, we enabled link-time optimisation for the Linux build, which caused some issues.
Edit: Actually, we didn't. We've been linking statically against libstdc++ for the past seven months. I might be completely wrong here, then.
During start-up, Factorio transitively loads libtxc_dxtn.so which then makes calls to the system libstdc++.so to initialise standard I/O streams and install a locale facet – which is where the crash comes from. I'm assuming the two C++ standard library implementations – the static one in the factorio binary and the dynamic one loaded from libtxc_dxtn.so – don't cooperate very well. The fact that we build Factorio with GCC 5 and Ubuntu 14.04 is built with GCC 4 probably isn't helping either.
Some mystery still remains, however. libtxc_dxtn (which, remember, is the one making the call to the system libstdc++.so) is a C library. Not C++. And, indeed, on my Fedora 22 box, it doesn't use libstdc++.so at all:
Code: Select all
[nightshade] ~ % ldd /usr/lib/libtxc_dxtn.so
linux-gate.so.1 (0xf77f5000)
libc.so.6 => /lib/libc.so.6 (0xf75ef000)
/lib/ld-linux.so.2 (0x56629000)Code: Select all
oxyd@virt-ubuntu:/usr/lib/x86_64-linux-gnu$ ldd libtxc_dxtn.so
linux-vdso.so.1 => (0x00007ffc9294e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fccec9e4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fccec6de000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fccec319000)
/lib64/ld-linux-x86-64.so.2 (0x00007fccecf20000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fccec103000)It looks like it's no LTO for us on Linux.
I don't know what else to do with my life! lol
