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)
forgot to mention, gfortran installed via `pkg install gcc6`
export LD_LIBRARY_PATH=/usr/local/lib/gcc48
Sorry, should be gcc6, not gcc48.
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`
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.
Seems to be fixed now.