Bug 218330
| Summary: | [exp-run] Use the lang/gccX port(s) instead of lang/gcc for USE_GCC=yes | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Gerald Pfeifer <gerald> | ||||
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Many People | CC: | jbeich, ports-bugs | ||||
| Priority: | --- | Flags: | gerald:
exp-run?
|
||||
| Version: | Latest | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Bug Depends on: | 218470, 218474, 218482 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
Oh, nice! I've disliked gcc/g++ symlinks as GNU configure (i.e. from autoconf) picks them up by default for out-of-ports builds. g++ implies libstdc++ which either breaks build or runtime where libc++ is default. One of such projects is Firefox. With this change using packages that depend on gccX and contributing upstream is going to be easier. Hopefully, not many ports have regressed to ignore CC/CXX/CPP since those symlinks got introduced. Those 3 ports depend directly on lang/gcc: devel/linux-kernel devel/stack www/thundercache (In reply to Antoine Brodin from comment #2) > Those 3 ports depend directly on lang/gcc: > > devel/linux-kernel > devel/stack > www/thundercache That should not be an issue, since (even after this patch) lang/gcc still exists and provides "everything". Did you see any actual breakage due to this? (And in the following stage lang/gcc will become a "shell" that requires lang/gcc5, so things should still be covered as well.) 4 new failures on 11.0 amd64:
+ {"origin"=>"devel/stack", "phase"=>"run-depends", "errortype"=>"???"}
+ {"origin"=>"games/eduke32", "phase"=>"build", "errortype"=>"assumes_gcc"}
+ {"origin"=>"multimedia/handbrake", "phase"=>"configure", "errortype"=>"configure_error"}
+ {"origin"=>"sysutils/fusefs-lkl", "phase"=>"build", "errortype"=>"process_failed"}
Failure logs:
http://package18.nyi.freebsd.org/data/110amd64-default-PR218330/2017-04-06_19h28m41s/logs/errors/stack-1.4.0.log
http://package18.nyi.freebsd.org/data/110amd64-default-PR218330/2017-04-06_19h28m41s/logs/errors/eduke32-20170225_1.log
http://package18.nyi.freebsd.org/data/110amd64-default-PR218330/2017-04-06_19h28m41s/logs/errors/handbrake-1.0.3.log
http://package18.nyi.freebsd.org/data/110amd64-default-PR218330/2017-04-06_19h28m41s/logs/errors/fusefs-lkl-4.8.493_2.log
Looks we are now clean short of a single port sysutils/fusefs-lkl aka bug #218475. Any help with that would be appreciated; I'll propose a patch there in a minute, but am not an expert in that area. A commit references this bug: Author: gerald Date: Mon May 1 08:42:19 UTC 2017 New revision: 439860 URL: https://svnweb.freebsd.org/changeset/ports/439860 Log: Replace USE_GCC=yes by a strict build dependency on lang/gcc since only that guarantees that a binary (or actually symlink) named gcc is present which this ports apparently requires. USE_GCC=yes allows users to adjust the default version of GCC via Mk/bsd.defaults-versions.mk, and with the change coming via PR218330 lang/gcc5 is going to be used instead of the (nearly identical, for now) lang/gcc shortly. PR: 218475, 218330 Approved by: cem (maintainer) Changes: head/sysutils/fusefs-lkl/Makefile PR 218475 was "fixed" (more like: worked around in a way), so I believe this patch can now proceed, correct? It seems ok. If there is more fallout after it is committed I will let you know Thanks, Antoine. I went ahead and committed this, alas forgot to reference this PR. For the record: Author: gerald Date: Tue May 2 05:40:53 2017 New Revision: 439929 URL: https://svnweb.freebsd.org/changeset/ports/439929 Log: As of today, USE_GCC=yes (and USE_GCC=any in most circumstances) and consequently many of the USES=compiler flavors use the canonical version of GCC as defined in Mk/bsd.default-versions.mk as well as the lang/gcc port With the "new" setup starting with GCC 5 where I have introduced lang/gcc5-devel for regular snapshots and lang/gcc5 for releases, and similarly for GCC 6 and onward, we can now leverage lang/gcc5 (and later) for most of the role that lang/gcc used to play -- and indeed as of today lang/gcc and lang/gcc5 are nearly identical short of symlinks for gcc, g++, and gfortran binaries that the former provides. So now use lang/gcc5 instead of lang/gcc whenever requested via the USE_GCC framework directly or indirectly. This is similar to how the python ports work, for example, and it allows simplifications in Mk/bsd.gcc.mk and Mk/Uses/fortran.mk and dropping LANG_GCC_IS from Mk/bsd.default-versions.mk. As a next step lang/gcc is going to become a "hull" essentially only providing those symlinks and requiring lang/gcc5 (or whatever has been set as default in Mk/bsd.default-versions.mk). Modified: head/Mk/Uses/fortran.mk head/Mk/bsd.default-versions.mk head/Mk/bsd.gcc.mk |
Created attachment 181428 [details] Proposed patch As of today, USE_GCC=yes (and USE_GCC=any in most circumstances) and consequently many of the USES=compiler settings use the canonical GCC port lang/gcc. With the new setup where I have introduced lang/gcc5-devel for weekly snapshots and lang/gcc5 for releases, and similarly for GCC 6 and onward, we can easily leverage lang/gcc5 (and later ports) for that role and indeed of today lang/gcc and lang/gcc5 are nearly identical (short of symlinks for gcc, g++, and gfortran binariesthe former provides). Once this patch has been tested successfully and committed, the next step will be stripping down lang/gcc to serve a similar function as lang/python. But, one step at a time. ;-)