On Matthias's archive rebuild for Xenial, we see build failures for lua5.1, lua5.2, and lua5.3 on powerpc:
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20160401-xenial.html
I've done some investigation, but not found the source of the problems. Trying to capture what I know here.
The build fails because part of the build tries to run `src/lua5.3 -v` and that segfaults. It crashes after main() exits in _IO_wsetb() in glibc's wgenops.c:105. This is because f->_wide_data points to bogus data. Setting a breakpoint in main() doesn't help because the data is already corrupted by then. Setting a breakpoint in _start or _init and then a watchpoint on this point shows that it gets corrupted in _IO_check_libio() in glibc's oldstdfiles.c. We then thought the likely culprit was compilation with g++ but linkage with gcc, however fixing that to compile and link *everything* with g++ doesn't solve the problem. This is the change we made in 5.3.1-1ubuntu1, which can be thrown away.
But the problem *is* related to lua5.3's d/patches/0001-build-system.patch because if you remove that from the quilt stack, you end up with a src/lua (not version numbered) for which `lua -v` doesn't segfault.
My only other thought was that maybe libtool was corrupting things, but I wasn't able to prove that. I tried various other transformations of that patch without success.
I've tested building this with either all gcc or all g++, and the result is the same.
At this point I suspect a regression in glibc 2.23. I don't think lua is doing anything particularly fancy here, yet at the time the binary is built, stdout points to a place in memory (possibly read-only) that's too small for a struct _IO_FILE_complete, yet glibc nevertheless tries to cast to this in the destructor and then gets very sad.
It seems that it is possible to work around this by not passing the flags '-Wl,--
Comparing the symbols between the binaries linked with and without this version script shows the following important difference:
10030ab0 g DO .rodata 00000004 Base _IO_stdin_used
Seems like we probably want the executable to not hide that symbol.
OTOH seems like hiding that symbol shouldn't break the binary? which is happening only on powerpc.