Bug 211889 - gfortran fails to link programs against the correct libgcc
Summary: gfortran fails to link programs against the correct libgcc
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Some People
Assignee: Kubilay Kocak
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-16 05:24 UTC by Jameson
Modified: 2016-08-16 12:43 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.