[Bug 208120] devel/cmake: Strips necessary rpath when installing any GNU compiler from ports

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208120

--- Comment #20 from Diane Bruce <db at 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.