Bug 211889

Summary: gfortran fails to link programs against the correct libgcc
Product: Ports & Packages Reporter: Jameson <vtjnash>
Component: Individual Port(s)Assignee: Kubilay Kocak <koobs>
Status: Closed FIXED    
Severity: Affects Some People CC: arrowd, rhurlin, w.schwarzenfeld
Priority: ---    
Version: Latest   
Hardware: i386   
OS: Any   

Description Jameson 2016-08-16 05:24:48 UTC
sample program:
```
$ cat hello.f
       program hello
          print *, "Hello World!"
       end program hello
$ gfortran6 hello.f
$ ./a.out
/lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc6/libgfortran.so.3
```

With the `-Wl,-rpath,/usr/local/lib/gcc6` flag recommended by `pkg install gcc` it does run successfully. But it seems that a compiler should be able to link itself (e.g. I haven't had the problem before with other non-default compilers on other systems)?

(noticed because ./configure in arpack immediately failed with the above error)

(tested with FreeBSD 11.0-rc1, downloaded as a VM image)
Comment 1 Jameson 2016-08-16 05:27:09 UTC
forgot to mention, gfortran installed via `pkg install gcc6`
Comment 2 Walter Schwarzenfeld freebsd_triage 2016-08-16 06:09:25 UTC
export LD_LIBRARY_PATH=/usr/local/lib/gcc48
Comment 3 Walter Schwarzenfeld freebsd_triage 2016-08-16 06:37:51 UTC
Sorry, should be gcc6, not gcc48.
Comment 4 Jameson 2016-08-16 08:12:40 UTC
Right, (I had also tried with both those versions of gcc). I know about that LD_LIBRARY_PATH workaround, I wanted to know whether it was possible to have gfortran manage to build correctly on its own.
Could it search its own path (`/usr/local/lib/gcc6`) before `/lib`, or to hide libgcc_s.so from the default search path, or some similar such action (does -rpath-link do this?). It seems pkg doesn't contain a version of gcc old enough to use with this library file, so I can't use that approach.

Some things that seemed to work:
  - adding `-rpath=/usr/local/lib/gcc48` to /usr/local/lib/gcc48/libgfortran.spec
  - deleting `/lib/libgcc_s.so.1`
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2016-08-16 08:35:13 UTC
Thank you for the report Jameson

I'm hunting this down for this and related issues in many ports that are a consequence of what appears to be this underlying issue. See bug 207750 as an example, ignore the "depends on bug 208120" part, it doesn't.

The spec suggestion looks interesting.
Comment 6 Gleb Popov freebsd_committer freebsd_triage 2020-04-27 20:52:56 UTC
Seems to be fixed now.