[gentoo-dev] Re: [PATCH] gcc-config: Add option to not install cc/f77 wrappers.

[Sergei Trofimovich <slyfox@gentoo.org>]

On Tue, 10 Mar 2020 20:54:12 -0700
Manoj Gupta <manojgupta@google.com> wrote:

> On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich <slyfox@gentoo.org> wrote:
> 
> > On Mon, 2 Mar 2020 19:03:48 -0800
> > Manoj Gupta <manojgupta@google.com> wrote:
> >  
> > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <slyich@gmail.com>
> > > wrote:
> > >  
> > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta <manojgupta@google.com>  
> > wrote:  
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <manojgupta@google.com>  
> >  
> > > > 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 <manojgupta@google.com>
> > > > >> ---
> > > > >>  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 .  
> > > > >  
> > > >
> > > > toolchain@gentoo.org 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