[Bug libc/21936] gcc build hangs with glibc 2.26 (conftest about static binaries dlopening themselves)

["fweimer at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21936

--- Comment #8 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Felix von Leitner from comment #7)
>   $ nm /usr/lib/libc.a 2>&1 | grep -w strchr
>   strchr.o:
>   00000000 T strchr

This is a bit suspicious.  It should show something like this, to mark the
symbol as an IFUNC resolver:

  00000000 i strchr

What does “readelf -W -s” report for this symbol?

Can you attach the strchr.o object file?

> Disassembly of section .text:
> 
> 00000000 <strchr>:
>    0:   8d 05 00 00 00 00       lea    0x0,%eax
>                         2: R_386_32     __strchr_ia32

That's not unusual per se because objdump has some trouble to interpret the
IFUNC resolver symbol information.  I get the same output for a properly
compiled strchr.o file.

> Why the hell would the IFUNC stuff be in the statically linked libc in the
> first place? I thought that is just for runtime resolving during dynamic
> linking?

IFUNC resolvers are used in statically linked binaries as well.  The startup
code performs minimal relocation to set this up (look for apply_irel in the
dynamic linker sources).

> My gcc 7.1 binary is even older than my binutils and glibc builds.

What does “gcc -v” show?  Was it compiled with --enable-gnu-indirect-function?

-- 
You are receiving this mail because:
You are on the CC list for the bug.