|Summary:||Mk/bsd.gcc.mk: GCC runtime should be optional|
|Product:||Ports & Packages||Reporter:||Pedro F. Giffuni <pfg>|
|Component:||Ports Framework||Assignee:||Gerald Pfeifer <gerald>|
|Severity:||Affects Some People||CC:||emaste, fabian.freyer, gerald, portmgr, ports-bugs|
Description Pedro F. Giffuni 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 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 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 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 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 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 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 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 ***