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

[Sergei Trofimovich]

On Tue, 26 May 2020 15:13:47 -0700
Manoj Gupta <manojgupta@××××××.com> wrote:

> I noticed that gcc-config recently gained --enable-native-links /
> --disable-native-links knobs that are . Will this patch with a renamed
> option name
> e.g. --disable-default-cc-vars and support for a USE flag work?

That can work. Let's try and see how the end result looks like.

> Thanks,
> Manoj
>
> On Wed, Mar 11, 2020 at 9:07 AM Manoj Gupta <manojgupta@××××××.com> wrote:
>
> >
> >
> > On Wed, Mar 11, 2020 at 12:49 AM Sergei Trofimovich <slyfox@g.o>
> > wrote:
> >
> >> On Tue, 10 Mar 2020 20:54:12 -0700
> >> Manoj Gupta <manojgupta@××××××.com> wrote:
> >>
> >> > On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich <slyfox@g.o>
> >> wrote:
> >> >
> >> > > On Mon, 2 Mar 2020 19:03:48 -0800
> >> > > Manoj Gupta <manojgupta@××××××.com> wrote:
> >> > >
> >> > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich <
> >> slyich@×××××.com>
> >> > > > wrote:
> >> > > >
> >> > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta <manojgupta@××××××.com>
> >>
> >> > > wrote:
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta <
> >> manojgupta@××××××.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@××××××.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@g.o 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?
> >>
> >> This is only for Chrome OS setup where I want to  switch "cc" to point to
> > clang or a different compiler (Switching will be done using a
> > different ebuild not used in Gentoo).
> > I do not want to disturb Gentoo's current setup in any way other than
> > adding an option to "gcc-config"
> > that will serve our needs.
> >
> > 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.
> >>
> >
> > Yes, this is exactly what I'd like but some internal teams want '$ make'
> > to work
> > as is. This option to "not install" these links will be a good first step
> > to find out
> > if there are any packages relying on 'cc' being present in Chrome OS
> > builds.
> >
> > Thanks,
> > Manoj
> >
> >
> >> --
> >>
> >>   Sergei
> >>
> >


-- 

  Sergei