On Tue, 26 May 2020 15:13:47 -0700 Manoj Gupta <manojgu...@google.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 <manojgu...@google.com> wrote: > > > > > > > On Wed, Mar 11, 2020 at 12:49 AM Sergei Trofimovich <sly...@gentoo.org> > > wrote: > > > >> On Tue, 10 Mar 2020 20:54:12 -0700 > >> Manoj Gupta <manojgu...@google.com> wrote: > >> > >> > On Tue, Mar 3, 2020 at 1:17 AM Sergei Trofimovich <sly...@gentoo.org> > >> wrote: > >> > > >> > > On Mon, 2 Mar 2020 19:03:48 -0800 > >> > > Manoj Gupta <manojgu...@google.com> wrote: > >> > > > >> > > > On Thu, Feb 27, 2020 at 11:20 PM Sergei Trofimovich < > >> sly...@gmail.com> > >> > > > wrote: > >> > > > > >> > > > > On Thu, 27 Feb 2020 at 22:41, Manoj Gupta <manojgu...@google.com> > >> > >> > > wrote: > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > On Thu, Feb 27, 2020 at 11:22 AM Manoj Gupta < > >> manojgu...@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 <manojgu...@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 . > >> > > > > > > >> > > > > > >> > > > > toolch...@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? > >> > >> 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