[Bug 1570055] Re: FTBFS on powerpc

[Steve Langasek]

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,--version-script -Wl,../debian/version-script' to the link
command.

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.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to glibc in Ubuntu.
https://bugs.launchpad.net/bugs/1570055

Title:
  FTBFS on powerpc

Status in glibc package in Ubuntu:
  New
Status in lua5.3 package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1570055/+subscriptions