Re: Test suite crashes on PPC64

[Zack Weinberg <zackw at panix dot com>]

On Thu, Feb 22, 2018 at 5:40 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 02/22/2018 02:34 PM, Zack Weinberg wrote:
>> On powerpc64-unknown-linux-gnu, with unmodified master glibc and GCC
>> 7, I'm seeing the test suite fall over while trying to build locales:
>>
>> Generating locale de_DE.ISO-8859-1: this might take a while...
>> Inconsistency detected by ld.so: get-dynamic-info.h: 146:
>> elf_get_dynamic_info: Assertion `info[DT_RUNPATH] == NULL' failed!
>> Charmap: "ISO-8859-1" Inputfile: "de_DE" Outputdir: "de_DE.ISO-8859-1" failed
>> /bin/sh: line 3:
>> /home/zackw/glibc/build-normal/localedata/de_DE.ISO-8859-1/LC_CTYPE.test-result:
>> No such file or directory
>> make[2]: *** [/home/zackw/glibc/build-normal/localedata/de_DE.ISO-8859-1/LC_CTYPE]
>> Error 1
>>
>> Anyone have any idea what might be wrong?  This makes it hard to debug
>> my scanf patches...
>
> This is quite odd.
>
> I doubt that ld.so has a DT_RUNPATH, but rather that something related to static
> PIE has been misconfigured in your build.
>
> Are you building with --enable-static-pie?

No. But in fact ld.so *does* have a DT_RUNPATH:

$ readelf -d ./elf/ld.so
Dynamic section at offset 0x2e8a8 contains 21 entries:
  Tag        Type                         Name/Value
 0x000000000000000e (SONAME)             Library soname: [ld64.so.1]
 0x000000000000001d (RUNPATH)            Library runpath: [/opt/at11.0/lib64]
 0x0000000000000004 (HASH)               0x1b8
 0x000000006ffffef5 (GNU_HASH)           0x2a0
 0x0000000000000005 (STRTAB)             0x750
 0x0000000000000006 (SYMTAB)             0x3a8
 0x000000000000000a (STRSZ)              616 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x40f88
 0x0000000000000002 (PLTRELSZ)           192 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x39c8
 0x0000000070000000 (PPC64_GLINK)        0x27d10
 0x0000000000000007 (RELA)               0xad0
 0x0000000000000008 (RELASZ)             12024 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)             0xa08
 0x000000006ffffffd (VERDEFNUM)          6
 0x000000006ffffff0 (VERSYM)             0x9b8
 0x000000006ffffff9 (RELACOUNT)          498
 0x0000000000000000 (NULL)               0x0

This points the finger at the compiler I was using.  This is on
compile-farm host gcc110.fsffrance.org, and /usr/bin/gcc is 4.8, which
is too old to build glibc trunk, so I went poking around the
filesystem and found something 7.2-ish in /opt:

$ which gcc
/opt/at11.0/bin/gcc
$ gcc --version
gcc (GCC) 7.2.1 20171116 (Advance-Toolchain-at11.0) [ibm/gcc-7-branch
revision 254526]

... and it's got all sorts of weird shit in its -dumpspecs output.
*sigh* I guess I have to build GCC myself after all.  And probably
also binutils.

zw