Test suite crashes on PPC64

Test suite crashes on PPC64

[Zack Weinberg]

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...

zw

Re: Test suite crashes on PPC64

[Carlos O'Donell]

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?

-- 
Cheers,
Carlos.

Re: Test suite crashes on PPC64

[Zack Weinberg]

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

Re: Test suite crashes on PPC64

[Joseph Myers]

On Thu, 22 Feb 2018, Zack Weinberg wrote:

> *sigh* I guess I have to build GCC myself after all.  And probably
> also binutils.

I think that if you run the "compilers" stage of build-many-glibcs.py for 
a single configuration, the resulting installed tools, if it's for a 
configuration that can run natively on the system you are using, should be 
entirely suitable for doing native build / test of glibc.

(Caveat regarding using build-many-glibcs.py on Power systems: it defaults 
parallelism to the number of CPU cores reported by the operating system, 
but some Power systems have a number of hardware threads that is much 
larger than an actual sensible level of parallelism.  So you may want to 
specify a -j option to avoid it defaulting to something like -j160.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Test suite crashes on PPC64

[Tulio Magno Quites Machado Filho]

Zack Weinberg <zackw@panix.com> writes:

> 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.

You can still use its AT 11.0 binutils safely.
Only GCC has a patch to change the RUNPATH.

-- 
Tulio Magno