[Bug nptl/5784] Fix static linking with -lpthread.

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

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

--- Comment #10 from Florian Weimer <fweimer at redhat dot com> ---
Backtrace:

#0  0x0000000000000000 in ?? ()
#1  0x000000000040c645 in close_unit_1 ()
#2  0x000000000040c78a in _gfortrani_close_units ()
#3  0x0000000000463914 in call_fini ()
#4  0x000000000046c80a in __run_exit_handlers ()
#5  0x000000000046c96e in exit ()
#6  0x0000000000463daf in __libc_start_call_main ()
#7  0x0000000000465d18 in __libc_start_main_impl ()
#8  0x00000000004039b5 in _start ()

Crash location:

   0x000000000040c639 <+233>:   lea    0xe0(%rbx),%rdi
   0x000000000040c640 <+240>:   call   0x0
=> 0x000000000040c645 <+245>:   mov    %rbx,%rdi

So this is a weak symbol.

Looking at the symbol table:

File: /usr/lib/gcc/x86_64-redhat-linux/13/libgfortran.a(unit.o)
[…]
   102: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND __pthread_key_create
   103: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
pthread_mutex_destroy
   104: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_mutex_unlock
   105: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND
pthread_mutex_trylock
   106: 0000000000000000     0 NOTYPE  WEAK   DEFAULT  UND pthread_mutex_lock

This is a GCC bug. It should not use weak symbols in static builds. Or dynamic
builds, but there it doesn't matter anymore since glibc 2.34. I think we
cleaned all this up for libstdc++, looks like we missed libgfortran.

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