Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#55220 - [testing/gcc] Message: Relink `/usr/lib/libgfortran.so.4' with `/usr/lib/libpthread.so.0' for IFUNC

Attached to Project: Arch Linux
Opened by Bastian Beranek (totsilence) - Monday, 21 August 2017, 10:13 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Saturday, 09 September 2017, 08:40 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

After updating gcc, gcc-libs and gcc-fortran from 7.1.1-4 to 7.2.0-2 I see the following message when starting some executables:

R: Relink `/usr/lib/libgfortran.so.4' with `/usr/lib/libpthread.so.0' for IFUNC symbol `system'

An example executable which shows this problem is 'R' from the package 'r':

$ R
/usr/lib64/R/bin/exec/R: Relink `/usr/lib/libgfortran.so.4' with `/usr/lib/libpthread.so.0' for IFUNC symbol `system'

R version 3.4.1 (2017-06-30) -- "Single Candle"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

The problem does not go away when rebuilding R with gcc 7.2.0-2. More importantly (for me) some other programs from my own software (for work, not part of any packages) also show the same message.

This problem started with gcc 7.2.0-2. (I have seen the same problem when building GCC master (8.x) from the gcc-git package in the AUR, but maybe I didn't build that gcc package properly, i.e. I didn't use a clean chroot and didn't compile the full toolchain, just gcc-git).
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Saturday, 09 September 2017, 08:40 GMT
Reason for closing:  Fixed
Additional comments about closing:  2.26-3
Comment by Bastian Beranek (totsilence) - Tuesday, 22 August 2017, 08:34 GMT
One might think that the glibc update to 2.26 could also be responsible for the problem, but when I built gcc-git from the AUR I was still using glibc 2.25. Also, downgrading glibc to 2.25 does not fix it either, while downgrading gcc, gcc-libs and gcc-fortran to 7.1.1-4 does.

I already checked the git log for GCC d791474f3fc2133fa0c310e566988b0cbdff321e..gcc-7_2_0-release (i.e. the range from the commit used for 7.1.1-4 to 7.2.0-2), but I can't find anything related, unfortunately.

I will try to provide a minimal reproducer which does not require building a complex executable such as 'R'.
Comment by Bastian Beranek (totsilence) - Wednesday, 23 August 2017, 10:04 GMT
The relocation type on the system symbol differs between libgfortran.so.4 in gcc-libs 7.2.0-2 and gcc-libs 7.1.1-4:

$ readelf -r /usr/lib/libgfortran.so.4 | grep system
0000003da898 004600000006 R_X86_64_GLOB_DAT 0000000000000000 system@GLIBC_2.2.5 + 0

If I do the same with libgfortran.so from gcc-libs 7.1.1-4:

$ readelf -r libgfortran.so | grep system
0000003db3c0 004600000007 R_X86_64_JUMP_SLO 0000000000000000 system@GLIBC_2.2.5 + 0

Indeed, if I put the 7.1.1-4 libgfortran in front in my LD_LIBRARY_PATH the error disappears.

Comment by Bastian Beranek (totsilence) - Wednesday, 23 August 2017, 10:09 GMT
Probably a result of -z,relro,-z,now in LDFLAGS? But I thought these flags had been already used for gcc-libs 7.1.1-4?
Comment by Bartłomiej Piotrowski (Barthalion) - Wednesday, 23 August 2017, 13:38 GMT
Yes, they were used also for 7.1.1-4. (Sorry for not being more involved – tough week…).
Comment by Bastian Beranek (totsilence) - Thursday, 24 August 2017, 11:41 GMT
I have rebuilt GCC 7.1.1-4 with current toolchain and it also shows the problem. Then I checked GNU binutils, and I found that 2.28-4 with --enable-relro configure flag was commited to SVN July 10th and GCC 7.1.1-4 was built June 30th, so I'm thinking that this could be the reason.
Comment by Bartłomiej Piotrowski (Barthalion) - Tuesday, 05 September 2017, 07:26 GMT
Re-opening as I implemented the workaround only for R, but it still can happen for other projects.
Comment by Bastian Beranek (totsilence) - Tuesday, 05 September 2017, 12:22 GMT
I managed to put together an example which does not depend on external libraries, but mimics the situation and reproduces the problem.

- libgfortran_dummy.so is a replacement for libgfortran.so.
It contains two functions: One of them calls system() ("gfortran_func_which_calls_system"), the other one does not ("gfortran_func").
But there's no reference to pthread (or pthread_dummy in my case) at all.

- libpthread_dummy.so is a replacement for libpthread.so.
It contains a function which is meant to be called by the user ("pthread_func"), and an IFUNC declaration of system, which is supposed to just forward the call to the libc system function.
This is the same situation as in the real libpthread.so.

- main.c: Calls "pthread_func" from libpthread_dummy.so and "gfortran_func" from libgfortran_dummy.so.

Compile with "make". Run with "export LD_LIBRARY_PATH=$PWD:$LD_LIBRARY_PATH" and then "./test". This is the output:

$ make
gcc -o main.o main.c -O0 -g -fPIC -fstack-protector-strong -fno-plt -c
gcc -o pthread_dummy.o pthread_dummy.c -O0 -g -fPIC -fstack-protector-strong -fno-plt -c
gcc -o pthread_dummy_ifunc.o pthread_dummy_ifunc.c -O0 -g -fPIC -fstack-protector-strong -fno-plt -c
gcc -o gfortran_dummy.o gfortran_dummy.c -O0 -g -fPIC -fstack-protector-strong -fno-plt -c
gcc -o libpthread_dummy.so pthread_dummy.o pthread_dummy_ifunc.o -Wl,--sort-common,--as-needed,-z,relro,-z,now -shared
gcc -o libgfortran_dummy.so gfortran_dummy.o -Wl,--sort-common,--as-needed,-z,relro,-z,now -shared
gcc -o test main.o -Wl,--sort-common,--as-needed,-z,relro,-z,now -L. -lpthread_dummy -lgfortran_dummy

$ ./test
./test: Relink `/home/beischer/ifunc/reproducer/libgfortran_dummy.so' with `/home/beischer/ifunc/reproducer/libpthread_dummy.so' for IFUNC symbol `system'
gfortran_func
ptread_func

The "Relink ..." message goes away in case the Arch specific flags in CFLAGS and LDFLAGS are removed. It also goes away when changing the order of -lpthread_dummy and -lgfortran_dummy in LDFLAGS_MAIN (see Makefile). But since these two libraries are seemingly independent, there should not be any relevance of the order in which they are linked.

In case the Arch specific flags are removed from CFLAGS and LDFLAGS it is enough to add '-fno-plt' to the compiler command for gfortran_dummy.o to make the problem reappear.

If one uncomments the call to "gfortran_func_which_calls_system" in main.c the program crashes.
Comment by Bastian Beranek (totsilence) - Tuesday, 05 September 2017, 13:38 GMT
I'm attaching a second project which reproduces the problem using the real system libgfortran.so and libpthread.so.
Comment by Bastian Beranek (totsilence) - Thursday, 07 September 2017, 12:47 GMT
Good news! I made some progress and found an glibc upstream bug report:

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

I will try if applying the patches there fixes the problem.
Comment by Bastian Beranek (totsilence) - Thursday, 07 September 2017, 13:24 GMT
These patches indeed fix the problem:

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fc5ad7024c620cdfe9b76e94638aac83b99c5bf8
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=40c06a3d0450365e9675fe26f34fc56ce8497325
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=5797b410a87f6f6f6d3661d730fac320cbd5f270

(one of them only adds the corresponding test)
I'd be grateful if these could be backported to glibc 2.26 in testing. Afterwards this bug report can be closed.
Comment by Bartłomiej Piotrowski (Barthalion) - Friday, 08 September 2017, 12:48 GMT
Thanks Bastian. I can confirm that glibc-2.26-3 that includes fc5ad7 passes your test case. I will close the issue after your confirmation.
Comment by Bastian Beranek (totsilence) - Saturday, 09 September 2017, 08:30 GMT
Yes, bug fixed. Please close!

Loading...