Bug 210199 - games/fretsonfire: ImportError: /lib/libgcc_s.so.1 is not installed with FretsOnFire
Summary: games/fretsonfire: ImportError: /lib/libgcc_s.so.1 is not installed with Fret...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Jose Alonso Cardenas Marquez
URL:
Keywords: needs-qa
Depends on: 230115
Blocks:
  Show dependency treegraph
 
Reported: 2016-06-11 03:50 UTC by Ryan McCoskrie
Modified: 2019-05-09 03:02 UTC (History)
8 users (show)

See Also:
koobs: maintainer-feedback? (acm)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan McCoskrie 2016-06-11 03:50:37 UTC
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
Comment 1 Diane Bruce freebsd_committer 2016-06-11 11:48:52 UTC
This is due to numpy using gfortran. This bug has affected many ports. Basically you have base libgcc_s.so linked and anything needing libquadmath needs port libgcc_s. Try setting LD_LIBRARY_PATH to /usr/local/lib/gcc${VER} where VER is the gcc version being used.

Also see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-11 11:52:30 UTC
Correctly set summary, assign to maintainer and use see also field.
Comment 3 Diane Bruce freebsd_committer 2016-06-12 11:30:57 UTC
See https://people.freebsd.org/~db/libgcc_summary.txt
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2016-06-16 13:44:02 UTC
@Diane, could you include the log linked in comment 3 as an attachment please
Comment 5 Diane Bruce freebsd_committer 2016-06-16 17:40:07 UTC
Using this test program sum.f90 provided by groot@kde.org (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120)
I can duplicate this bug:

! 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

./sum
/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortr
an.so.3 not found

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)

What is happening is sum has been linked with the base version of libgcc in
/lib/libgcc_s.so.1

When sum is loaded our libgcc is loaded then libgfortran which has
a dependency on a later version of gcc than the version we claim to support
in base.

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 <mod
ule>
    from GameEngine import GameEngine
  File "/usr/local/lib/fretsonfire/FretsOnFire/GameEngine.py", line 34, in <modu
le>
    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, i
n <module>
    from numpy.lib import add_newdoc
  File "/usr/local/lib/python2.7/site-packages/numpy/lib/__init__.py", line 8, i
n <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/gc
c48/libgfortran.so.3 not found

What has happened is the game has a dependency on py-numpy which brings
in the fortran support.

Summary
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}

It does not help that compiler.mk does not enforce the -Wl,rpath= for an
extern gcc compiler in CFLAGS etc.

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

This is deliberate behaviour by cmake designers.

https://cmake.org/Wiki/CMake_RPATH_handling#Default_RPATH_settings

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

A simple fix for ports using cmake without the compiler.mk patch
is to add something like this to the Makefile.

CMAKE_ARGS+=     -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}"
Comment 6 Tijl Coosemans freebsd_committer 2016-08-19 13:29:52 UTC
Can you run the following commands and post the output of kdump:

cd /tmp
env LD_UTRACE=1 ktrace -t u FretsOnFire
kdump
Comment 7 Walter Schwarzenfeld freebsd_triage 2018-01-13 22:51:35 UTC
Is this still a problem? Or is it still relevant?
Comment 8 Tijl Coosemans freebsd_committer 2018-01-16 16:38:50 UTC
We could link the python port with -Wl,-rpath=/usr/local/lib/gccX without adding a dependency on gcc.  That way python would use the newer libgcc_s if a gcc port is installed and fall back to base libgcc_s if not.
Comment 9 Nathan 2018-07-27 03:57:15 UTC
If this is gonna be updated, py-game, whenever I submit it, will have it's name changed to py-pygame. I've also updated ${PYGAME} to relect the new name, so that could be used now, so when I do submit and it gets approved, won't have to update this port again?
Comment 10 Nathan 2018-07-28 17:48:08 UTC
(In reply to Nathan from comment #9)
> If this is gonna be updated, py-game, whenever I submit it, will have it's
> name changed to py-pygame. I've also updated ${PYGAME} to relect the new
> name, so that could be used now, so when I do submit and it gets approved,
> won't have to update this port again?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230115 Is the pending bug for updating py-game to py-pygame and version update
Comment 11 Katy Maras 2019-05-09 03:02:27 UTC
MARKED AS SPAM