Page MenuHomeFreeBSD
Paste P98

This is a summary of the libgcc_s error many people have reported.
ArchivedPublic
Actions

Authored by db on Jun 13 2016, 10:22 PM.
This is a summary of the libgcc_s error many people have reported.
"ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found"
Using this test program sum.f90 provided by groot@kde.org
see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120
We can demonstrate the fault.
! sum.f90
! Performs summations using in a loop using EXIT statement
! Saves input information and the summation in a data file
program summation
implicit none
integer :: sum, a
print*, "This program performs summations. Enter 0 to stop."
open(unit=10, file="SumData.DAT")
sum = 0
do
print*, "Add:"
read*, a
if (a == 0) then
exit
else
sum = sum + a
end if
write(10,*) a
end do
print*, "Summation =", sum
write(10,*) "Summation =", sum
close(10)
end
gfortran -o sum sum.f90
ldd sum
sum:
libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x800822000)
libm.so.5 => /lib/libm.so.5 (0x800b36000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d60000)
libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x800f6e000)
libc.so.7 => /lib/libc.so.7 (0x8011a3000)
On FreeBSD 9.3
This is responsible for the plethora of bugs such as
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210199
" When I attempt to launch the game I get the following back trace:
Traceback (most recent call last):
File "/usr/local/bin/FretsOnFire", line 16, in <module>
execfile(os.path.join(package_dir, "FretsOnFire.py"))
File "/usr/local/lib/fretsonfire/FretsOnFire/FretsOnFire.py", line 45, in <module>
from GameEngine import GameEngine
File "/usr/local/lib/fretsonfire/FretsOnFire/GameEngine.py", line 34, in <module>
from Data import Data
File "/usr/local/lib/fretsonfire/FretsOnFire/Data.py", line 23, in <module>
from Font import Font
File "/usr/local/lib/fretsonfire/FretsOnFire/Font.py", line 24, in <module>
import numpy
File "/usr/local/lib/python2.7/site-packages/numpy/__init__.py", line 180, in <module>
from . import add_newdocs
File "/usr/local/lib/python2.7/site-packages/numpy/add_newdocs.py", line 13, in <module>
from numpy.lib import add_newdoc
File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, in <module>
from .type_check import *
File "/usr/local/lib/python2.7/site-packages/numpy/lib/type_check.py", line 11, in <module>
import numpy.core.numeric as _nx
File "/usr/local/lib/python2.7/site-packages/numpy/core/__init__.py", line 14, in <module>
from . import multiarray
ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
"
Using the test program I can duplicate this bug:
./sum
/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
But on HEAD
ldd sum
sum:
libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x800822000)
libm.so.5 => /lib/libm.so.5 (0x800b36000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800d60000)
libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x800f6e000)
libc.so.7 => /lib/libc.so.7 (0x8011a3000)
./sum
This program performs summations. Enter 0 to stop.
Add:
...
Works fine!
What has changed?
on HEAD
strings /usr/local/lib/gcc46/libgfortran.so.3 |grep GCC
on FreeBSD 9.3
strings /usr/local/lib/gcc48/libgfortran.so.3 |grep GCC
GCC_4.2.0
GCC_3.0
GCC_3.3
GCC_4.6.0
on FreeBSD 9.3
readelf -V /usr/local/lib/gcc48/libgfortran.so > libgfortran_9_3.txt
Version symbols section '.gnu.version' contains 1450 entries:
Addr: 0000000000012540 Offset: 0x012540 Link: 2 (.dynsym)
...
{elided} see http://people.FreeBSD.org/~db/libgfortran_9_3.txt for full text
...
Version definition section '.gnu.version_d' contains 10 entries:
Addr: 0x0000000000013098 Offset: 0x013098 Link: 3 (.dynstr)
000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libgfortran.so.3
0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GFORTRAN_1.0
0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GFORTRAN_1.1
0x0054: Parent 1: GFORTRAN_1.0
0x005c: Rev: 1 Flags: none Index: 4 Cnt: 2 Name: GFORTRAN_1.2
0x0078: Parent 1: GFORTRAN_1.1
0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: GFORTRAN_1.3
0x009c: Parent 1: GFORTRAN_1.2
0x00a4: Rev: 1 Flags: none Index: 6 Cnt: 2 Name: GFORTRAN_1.4
0x00c0: Parent 1: GFORTRAN_1.3
0x00c8: Rev: 1 Flags: none Index: 7 Cnt: 2 Name: GFORTRAN_1.5
0x00e4: Parent 1: GFORTRAN_1.4
0x00ec: Rev: 1 Flags: none Index: 8 Cnt: 1 Name: F2C_1.0
0x0108: Rev: 1 Flags: none Index: 9 Cnt: 1 Name: GFORTRAN_C99_1.0
0x0124: Rev: 1 Flags: none Index: 10 Cnt: 2 Name: GFORTRAN_C99_1.1
0x0140: Parent 1: GFORTRAN_C99_1.0
Version needs section '.gnu.version_r' contains 4 entries:
Addr: 0x00000000000131e0 Offset: 0x0131e0 Link to section: 3 (.dynstr)
000000: Version: 1 File: libquadmath.so.0 Cnt: 1
0x0010: Name: QUADMATH_1.0 Flags: none Version: 15
0x0020: Version: 1 File: libgcc_s.so.1 Cnt: 4
0x0030: Name: GCC_4.2.0 Flags: none Version: 18
0x0040: Name: GCC_3.0 Flags: none Version: 17
0x0050: Name: GCC_3.3 Flags: none Version: 14
0x0060: Name: GCC_4.6.0 Flags: none Version: 13
0x0070: Version: 1 File: libc.so.7 Cnt: 2
0x0080: Name: FBSD_1.3 Flags: none Version: 20
0x0090: Name: FBSD_1.0 Flags: none Version: 12
0x00a0: Version: 1 File: libm.so.5 Cnt: 3
0x00b0: Name: FBSD_1.2 Flags: none Version: 19
0x00c0: Name: FBSD_1.1 Flags: none Version: 16
0x00d0: Name: FBSD_1.0 Flags: none Version: 11
On HEAD
readelf -V /usr/local/lib/gcc46/libgfortran.so> libgfortran_HEAD.txt
Version symbol section (.gnu.version):
000: 0 *local* 0 *local* 2 GFORTRAN_1.0 2 GFORTRAN_1.0
{elided} See http://people.FreeBSD.org/~db/libgfortran_HEAD.txt for full text
On HEAD sections '.gnu.version_r' and '.gnu.version_d' are missing entirely.
(why?)
Thus rtld does not reject our version of libgcc as being too old
and will run without flagging an error.
However:
1) we should never have our base libgcc_s linked in when using gcc from ports
or gfortran. We should always be having a RPATH to /usr/local/lib/gcc${VER}
where VER is the version of gcc / gfortran we used. 46 47 48 etc.
2) If we do link in our base libgcc_s it should still work, even though that
is wrong.
Anything linked with gcc (gcc compiler or gfortran) must have an rpath
to /usr/local/lib/gcc${VER}
e.g. looking at Uses/fortran
FFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
FCFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER}
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin
Bur our Uses/compiler for C does not have the -Wl,-rpath stanza
added in CFLAGS, CXXFLAGS or LDFLAGS
Next cmake.
Our cmake does not pass along the right invocation to keep the rpath
information.
See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120
Summary: The appropriate RPATH is in the compiled .so and binaries when
it is built but is stripped out as it is finally installed.
Thus anything linked with our cmake can run into this bug as well.
Simple fix to compiler.mk
Index: compiler.mk
===================================================================
--- compiler.mk (revision 416615)
+++ compiler.mk (working copy)
@@ -248,3 +248,7 @@
.endif
.endif
+
+.if ${CHOSEN_COMPILER_TYPE == gcc }
+CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"
+.endif
I will phabricator this
<bapt> db_: I think the best is you put your patch in phabricator
> bapt: I was thinking that.
<bapt> and cc peoples like tijl, gerald etc
> bapt: yes. moreover, it's not just cmake that needs the -Wl
> whenever gcc itself is used it should force an -Wl,rpath=
<bapt> hence cc gerald :)
> not just gfortran like gerald has done
> yeppers

Event Timeline

db created this paste.Jun 13 2016, 10:22 PM
db created this object in space S1 Global.
db edited the content of this paste. (Show Details)Jun 14 2016, 8:04 PM
gerald added a comment.Aug 4 2019, 2:47 PM

I believe this has been addressed by the following and its siblings, so am going to archive this.

r501438 | gerald | 2019-05-12 19:17:09 +0000 (So., 12 Mai 2019) | 44 lines

Forward port r499061 | gerald | 2019-04-15 from lang/gcc8 and gcc8-devel:

GCC has two runtime libraries:  The static library libgcc.a (-lgcc) and
the shared library libgcc_s.so (-lgcc_s).  Both implement many of the
same functions but they also each have their unique functions.  When
GCC links programs and libraries there are three possibilities:
gerald archived this paste.Aug 4 2019, 2:47 PM