On Tue, 10 Mar 2020 20:54:12 -0700 Manoj Gupta <[email protected]> wrote:
> On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich <[email protected]> wrote: > > > On Mon, 2 Mar 2020 19:03:48 -0800 > > Manoj Gupta <[email protected]> wrote: > > > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <[email protected]> > > > wrote: > > > > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta <[email protected]> > > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <[email protected]> > > > > > > wrote: > > > > >> > > > > >> gcc-config installs cc/f77 by default. This may be undesired on > > > > >> systems that want to set their own versions of cc/f77. > > > > >> > > > > >> Add option "-n"/"--no-default-vars" to not install the cc/f77 > > > > >> wrappers. > > > > >> > > > > >> Signed-off-by: Manoj Gupta <[email protected]> > > > > >> --- > > > > >> gcc-config | 6 +++++- > > > > >> 1 file changed, 5 insertions(+), 1 deletion(-) > > > > >> > > > > >> diff --git a/gcc-config b/gcc-config > > > > >> index f03a46a..6f306db 100755 > > > > >> --- a/gcc-config > > > > >> +++ b/gcc-config > > > > >> @@ -262,7 +262,7 @@ update_wrappers() { > > > > >> # For all toolchains, we want to create the fully qualified > > > > >> # `tuple-foo`. Only native ones do we want the simple > > `foo`. > > > > >> local all_wrappers=( ${new_wrappers[@]/#/${CTARGET}-} ) > > > > >> - if ! is_cross_compiler ; then > > > > >> + if ! is_cross_compiler && [[ "${DEFAULT_PROGS}" == "yes" > > ]]; > > > > then > > > > >> all_wrappers+=( "${new_wrappers[@]}" ) > > > > >> # There are a few fun extra progs which we have to > > > > handle #412319 > > > > >> all_wrappers+=( cc:gcc f77:g77 ) > > > > >> @@ -951,6 +951,7 @@ FORCE="no" > > > > >> CC_COMP= > > > > >> ENV_D="${EROOT}etc/env.d" > > > > >> GCC_ENV_D="${ENV_D}/gcc" > > > > >> +DEFAULT_PROGS="yes" > > > > >> > > > > >> for x in "$@" ; do > > > > >> case "${x}" in > > > > >> @@ -972,6 +973,9 @@ for x in "$@" ; do > > > > >> -l|--list-profiles) > > > > >> set_doit list_profiles > > > > >> ;; > > > > >> + -n|--no-default-vars) > > > > >> + DEFAULT_PROGS="no" > > > > >> + ;; > > > > >> -S|--split-profile) > > > > >> if [[ ( $1 != "-S" && $1 != > > "--split-profile" ) > > > > || $# -eq 1 ]] ; then > > > > >> usage 1 > > > > >> -- > > > > >> > > > > > > > > > > Not sure of the correct mailing list for patches to gcc-config so > > also > > > > adding toolchain@gentoo . > > > > > > > > > > > > > [email protected] should generally be fine. > > > > > > > > Today cc->gcc and gcc->${CHOST}-gcc symlinks are effectively owned by > > > > a single sys-devel/gcc-config package. > > > > gcc-config is calld to update symlinks every time sys-devel/gcc is > > > > installed/updated. That way we never get cc/gcc > > > > out of sync. > > > > > > > > Your change makes /usr/bin/cc an orphan symlink. I think we need to > > > > still keep a 'cc'/'f77' ownership somewhere > > > > (say, a separate package). > > > > > > > > I suggest making a decision to handle or not handle 'cc'/'f77' and > > > > gcc-config build-time, not gcc-config call-time. > > > > That way sys-devel/gcc updates will behave the same as manual > > > > 'gcc-config-' calls. > > > > > > > > Mechanically that could be a Makefile variable that switches the > > > > behaviour on/off at > > > > https://gitweb.gentoo.org/proj/gcc-config.git/tree/Makefile > > > > and exposed as an USE flag on sys-devel/gcc-config ebuild. > > > > > > > > Later we can create a separate ebuild to manage /usr/bin/cc. For gcc > > > > it's not hard, as gcc-config always provides /usr/bin/gcc and > > > > /usr/bin/${CHOST}-gcc. > > > > These can be static symlinks that don't require maintenance updates. > > > > > > > > Thanks for the suggestion. I will look into adding a Makefile > > variable > > > exposed via an USE flag. > > > > You might also need to look in the detail at 'c++', 'cpp' and ${CHOST}-* > > equivalents > > as those also get linked by gcc-config: > > > > $ LANG=C ls -l /usr/bin/ | fgrep 10.0.1 | fgrep -v -- '-10.0.1 ->' > > lrwxrwxrwx 1 root root 43 Feb 4 10:45 c++ -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/c++ > > lrwxrwxrwx 1 root root 43 Feb 4 10:45 cc -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc > > lrwxrwxrwx 1 root root 43 Feb 4 10:45 cpp -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/cpp > > lrwxrwxrwx 1 root root 43 Feb 4 10:45 g++ -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/g++ > > lrwxrwxrwx 1 root root 43 Feb 4 10:45 gcc -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc > > lrwxrwxrwx 1 root root 46 Feb 4 10:45 gcc-ar -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc-ar > > lrwxrwxrwx 1 root root 46 Feb 4 10:45 gcc-nm -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc-nm > > lrwxrwxrwx 1 root root 50 Feb 4 10:45 gcc-ranlib -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcc-ranlib > > lrwxrwxrwx 1 root root 45 Feb 4 10:45 gccgo -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gccgo > > lrwxrwxrwx 1 root root 44 Feb 4 10:45 gcov -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcov > > lrwxrwxrwx 1 root root 49 Feb 4 10:45 gcov-dump -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcov-dump > > lrwxrwxrwx 1 root root 49 Feb 4 10:45 gcov-tool -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcov-tool > > lrwxrwxrwx 1 root root 48 Feb 4 10:45 gfortran -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gfortran > > lrwxrwxrwx 1 root root 45 Feb 4 10:45 go-10 -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/go-10 > > lrwxrwxrwx 1 root root 48 Feb 4 10:45 gofmt-10 -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gofmt-10 > > lrwxrwxrwx 1 root root 48 Feb 4 10:45 lto-dump -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/lto-dump > > lrwxrwxrwx 1 root root 63 Feb 4 10:45 x86_64-pc-linux-gnu-c++ > > -> /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-c++ > > lrwxrwxrwx 1 root root 63 Feb 4 10:45 x86_64-pc-linux-gnu-cpp > > -> /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-cpp > > lrwxrwxrwx 1 root root 63 Feb 4 10:45 x86_64-pc-linux-gnu-g++ > > -> /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-g++ > > lrwxrwxrwx 1 root root 63 Feb 4 10:45 x86_64-pc-linux-gnu-gcc > > -> /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gcc > > lrwxrwxrwx 1 root root 66 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcc-ar -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gcc-ar > > lrwxrwxrwx 1 root root 66 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcc-nm -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gcc-nm > > lrwxrwxrwx 1 root root 70 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcc-ranlib -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gcc-ranlib > > lrwxrwxrwx 1 root root 65 Feb 4 10:45 > > x86_64-pc-linux-gnu-gccgo -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gccgo > > lrwxrwxrwx 1 root root 64 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcov -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gcov > > lrwxrwxrwx 1 root root 49 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcov-dump -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcov-dump > > lrwxrwxrwx 1 root root 49 Feb 4 10:45 > > x86_64-pc-linux-gnu-gcov-tool -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gcov-tool > > lrwxrwxrwx 1 root root 68 Feb 4 10:45 > > x86_64-pc-linux-gnu-gfortran -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/x86_64-pc-linux-gnu-gfortran > > lrwxrwxrwx 1 root root 45 Feb 4 10:45 > > x86_64-pc-linux-gnu-go-10 -> /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/go-10 > > lrwxrwxrwx 1 root root 48 Feb 4 10:45 > > x86_64-pc-linux-gnu-gofmt-10 -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/gofmt-10 > > lrwxrwxrwx 1 root root 48 Feb 4 10:45 > > x86_64-pc-linux-gnu-lto-dump -> > > /usr/x86_64-pc-linux-gnu/gcc-bin/10.0.1/lto-dump > > > > > Regarding the separate ebuild, I hope someone more knowledgeable > > > than me regarding ebuilds can handle that. > > > > How do you plan to manage those symlinks meanwhile? > > > > I guess there is a confusion in the scope of change I want to do. > > GCC package does not provide cc and f77 binaries or symlinks. These are > provided by the gcc-config > which adds /usr/bin/cc and /usr/bin/f77. > These are not needed for building packages via portage but were added > in https://bugs.gentoo.org/412319 just because it is nice to ensure that > invocations like > $ make > work as is without setting CC explicitly e.g. > $ CC=gcc make I'm afraid "not needed" is desired but not strictly true. I keep seeing packages that use 'cc' accidentally (dev-util/radare2) or explicitly. Don't know if most of them can safely fall back to 'gcc' at ./configure time. I suspect many don't. > I only want to change gcc-config to NOT create /usr/bin/cc and /usr/bin/f77 > via an option. > Everything else stays unchanged. I see. Initially you said you want to set your own 'cc' and 'f77' wrapper. Can you clarify what is the motivation to change only a subset of programs? Maybe describe whole intended setup? It feels very dangerous to have 'cc' point to one compiler (manually set) and 'c99' to another ('gcc'). We will start producing more inconsistent environments than we do today. Not installing 'cc'/'f77' at all might be less bad. -- Sergei
