https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120
--- Comment #20 from Diane Bruce <d...@freebsd.org> --- In comment #19 "It doesn't matter what compiler that port is compiled with (including clang!) so there are no (simple) hacks you can add to files under Mk or to cmake to detect this case. Just add USES=fortran (perhaps with a comment that explains why)." which brings us back to part of the original problem. ;) cmake subsystem is not truly honouring the spirit of USES=fortran as it is. Re-read groot's comment #15 "Personally I think that the build-system should DTRT as much as possible to deliver a working executable, and that the rpath-fix for gcc-compilers should be added in cmake." This suggests the proper fix would be in Modules/CheckFortranCompilerFlag.cmake to ensure the rpath is honoured. However, it would then miss the USES_GCC flag which also sets rpath in Mk/bsd.gcc.mk. I would suggest the fix needs to be applied to both Mk/bsd.gcc.mk and Mk/Uses/fortran.mk Something like the fix mentioned in comment #10 CMAKE_ARGS+= -DCMAKE_INSTALL_RPATH:STRING="${LOCALBASE}/lib/gcc${_GCC_VER}" I agree with the last part of comment #19 "Because Fortran as far as I know doesn't support exceptions, patching gfortran to remove -shared-libgcc would remove pretty much all links to libgcc_s from Fortran libraries. They would still link to libgfortran but there's no libgfortran in base to cause trouble. There could still be trouble when mixing libraries compiled with different versions of gfortran, which may happen on user systems when the default gcc version has been changed. In this case it would still be good if ports that depend on ports that have USES=fortran also set USES=fortran." with the caveat that we still have a problem when a program references libgcc_s and is running with base libgcc_s then dlopen's a module which was compiled against another libgcc_s not in base. In the case of a gfortran compiled module, it will "want" libgfortran which will "need" a later libgcc_s version than we currently support in base and *then* fail. ;) And as groot mentions we still do not DTRT without the make system 'helping'. (We cannot due to the name clash) I discussed this in depth with a few others from toolchains on IRC. The proposed fix I suggest is merely a stopgap until our libgcc_s can be brought up to date. We are missing (from the gfortran viewpoint) libquadmath. We could "lie" in our libgcc_s and it would be perfectly fine (BTW I've briefly tested this), but the better solution is not to bump the claimed version. e.g. readelf -a /usr/local/lib/gcc49/libgcc_s.so Version definition section '.gnu.version_d' contains 13 entries: Addr: 0x0000000000001fb8 Offset: 0x001fb8 Link: 3 (.dynstr) 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libgcc_s.so.1 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GCC_3.0 ... I don't have the final answer. All I want to do now is ensure this problem is well documented so others know the workaround. ;) -- You are receiving this mail because: You are the assignee for the bug.