Comment 1 Diane Bruce 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 2016-06-11 11:52:30 UTC

Correctly set summary, assign to maintainer and use see also field.

Comment 3 Diane Bruce 2016-06-12 11:30:57 UTC

See https://people.freebsd.org/~db/libgcc_summary.txt

Comment 4 Kubilay Kocak 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 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 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

Is this still a problem? Or is it still relevant?

Comment 8 Tijl Coosemans 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.

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?

(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

MARKED AS SPAM

Comment 12 Kubilay Kocak 2022-06-08 23:32:53 UTC

^Triage: Close feedback timeout. If this is still an issue (for any ports), please re-open with additional details and steps to reproduce on supported FreeBSD versions and an up to date ports tree and/or package repository