Bug 199897

Summary: Mk/bsd.gcc.mk: GCC runtime should be optional
Product: Ports & Packages Reporter: Pedro F. Giffuni <pfg>
Component: Ports FrameworkAssignee: Gerald Pfeifer <gerald>
Status: Closed DUPLICATE    
Severity: Affects Some People CC: emaste, fabian.freyer, gerald, portmgr, ports-bugs
Priority: --- Keywords: needs-qa
Version: Latest   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211079
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211154

Description Pedro F. Giffuni freebsd_committer freebsd_triage 2015-05-03 18:32:24 UTC
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 :(.
Comment 1 Gerald Pfeifer freebsd_committer freebsd_triage 2015-10-12 02:47:14 UTC
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.
Comment 2 Pedro F. Giffuni freebsd_committer freebsd_triage 2015-10-12 14:17:55 UTC
(In reply to Gerald Pfeifer from comment #1)

This sounds like a wishlist item for pkg(8).
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2015-10-19 10:23:55 UTC
@Pedro

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
Comment 4 Pedro F. Giffuni freebsd_committer freebsd_triage 2015-10-19 16:23:29 UTC
(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.
.
Comment 5 Baptiste Daroussin freebsd_committer freebsd_triage 2016-07-16 15:01:24 UTC
It is not something on pkg side, but on the port side, removing pkg@ from CC
Comment 6 Pedro F. Giffuni freebsd_committer freebsd_triage 2016-07-18 19:38:05 UTC
(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.
Comment 7 Gerald Pfeifer freebsd_committer freebsd_triage 2017-01-15 21:46:15 UTC
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 ***