Looking at /usr/ports/Mk/bsd.gcc.mk (line 156)
We link against the GCC runtime every time we USE_GCC in ports. This was done to work around the ABI differences with gcc-4.2.1 in base for FreeBSD >= 9.x.
FreeBSD 10.x or later could, of course, use the llvm runtime instead which would bring the advantage of not having to add the run dependencies on gcc after compiling the packages.
I think we should make this linking optional (and off by default for FreeBSD >=10). It would also be nice to have a way to use libc++ instead libstdc++ with gcc.
This is all way above my current ports makefile foo though :(.
I agree with most of this. (Using one's toolchain C++ run-time library
with binaries built by the other is probably tougher and more fragile
than the benefit.)
This is a clear case where having the ability to easily break one port
into several binary packages (as RPM has been doing for quite a while)
would be great.
Once we have this, certainly worth a try. Before that, and for the
time being, I won't be able to make this a priority.
(In reply to Gerald Pfeifer from comment #1)
This sounds like a wishlist item for pkg(8).
Given you created the report, and that it has been through portmgr@ -> gerald@, who needs to now be assigned, or what changes need to be made to progress the issue?
Does the summary need clarification?
Is this a pkg feature request @ upstream?
Feel free to re-assign/re-triage or resolve/close as necessary
(In reply to Kubilay Kocak from comment #3)
I opened the PR under request from emaste, while discussing the new
openmp support in clang 3.7, but that doesn't mean I know who should
fix it ;).
It looks like gerald wants support from the pkg maintainers but if
they decide the feature is not desirable, it's still an issue to
solve. I guess the issue should continue assigned to gerald.
It is not something on pkg side, but on the port side, removing pkg@ from CC
(In reply to Baptiste Daroussin from comment #5)
The wish for pkg is/was being able to split a package into many.
If I understand well, the idea is to be able to split out the runtime libraries from GCC. OpenOffice could use something like that for generating the SDK as well.
I think it is probably easier to get rid of the runtime libraries by making them an option in the port. For now the option would be on by default.
When we get LLVM Fortran (which I have heard is advancing very well) GCC/GFORTRAN will become of secondary importance and the GNU runtime can be deprecated.
PR 211154 actually came later than this, but it has actual code
proposed (even though that follows the more limited approach mandated
by limits of our packaging system compared to subpackages as RPM has
been supporting for a decade or two).
*** This bug has been marked as a duplicate of bug 211154 ***