Bug 427672 – Detect ignorance of CC & CXX (and other tools, like pkg-config?) through provision of gcc/g++/etc wrappers

• Product: Portage Development
• Status: CONFIRMED ---

[Description Michał Górny 2012-07-22 19:04:19 UTC]

Portage could provide wrappers for gcc & g++ in ebuild-helpers. Those would output eqawarn (and set some internal variable to avoid repetitive output) that CC/CXX is not respected and exec the actual gcc/g++.

I think it's the simplest way of detecting that and it shouldn't break build of those packages.

[Comment 1 Fabian Groffen 2012-07-22 19:09:15 UTC]

what if CC="gcc -m64"?

[Comment 2 Mike Gilbert 2012-07-22 19:12:30 UTC]

Shouldn't it be "$CHOST-gcc -m64"?

[Comment 3 Michał Górny 2012-07-22 19:14:27 UTC]

(In reply to comment #1)
> what if CC="gcc -m64"?

Quick guess: disable it if CC.split()[0] == 'gcc'?

[Comment 4 Fabian Groffen 2012-07-22 20:03:45 UTC]

ok, put differently:

CC=clang
CC=icc

[Comment 5 Mike Gilbert 2012-07-22 20:20:25 UTC]

In that case, the gcc wrapper would not be called.

[Comment 6 Fabian Groffen 2012-07-23 06:56:25 UTC]

so that is how you detect it's not respected? isn't really full proof to me
but in that optimistic mode, you'll need 'cc' then too

perhaps you better make dev feature that adds a directory to PATH containing dying scripts with the names cc, gcc, c++, g++, ld, gld, as, gas instead

no point in bothering non-cross-compiling users with this stuff, does it?

[Comment 7 Mike Gilbert 2012-07-23 07:21:56 UTC]

(In reply to comment #6)
> so that is how you detect it's not respected? isn't really full proof to me
> but in that optimistic mode, you'll need 'cc' then too

It is a simple way to trigger a QA check that should work in most situations.

If gcc is called in an ebuild where CC=clang, this will catch that. It would not detect if $CHOST-gcc is called instead of clang.

> perhaps you better make dev feature that adds a directory to PATH containing
> dying scripts with the names cc, gcc, c++, g++, ld, gld, as, gas instead

I already have that for gcc and g++. Making it a QA warning is a bit more polite, and allows broader coverage.

> no point in bothering non-cross-compiling users with this stuff, does it?

Huh? I think it is intended for ebuild maintainers, not users.

[Comment 8 Michał Górny 2012-07-24 10:05:25 UTC]

Created attachment 319074 [details, diff]
Initial patch

It's not perfect and not very complete but it works. We can add more variables in next patches if the approach is fine.

[Comment 9 SpanKY 2012-08-21 03:18:17 UTC]

this would also fail for packages that want to execute the native gcc because they're building helpers that get run during build time and never installed

[Comment 10 Michał Górny 2012-08-21 07:18:55 UTC]

(In reply to comment #9)
> this would also fail for packages that want to execute the native gcc
> because they're building helpers that get run during build time and never
> installed

Shouldn't those packages use some prefix as well? CBUILD?

[Comment 11 SpanKY 2012-08-21 23:24:06 UTC]

yes, we have tc-getBUILD_CC people can use.  but it'll take time to deploy as not all packages have a way to configure that -- they just execute `cc` and be done.  it is not something we've been diligent about at all.

along those lines, the warning from the current wrappers are misleading to be bad since it might not be a target issue, but a build one.  it also incorrectly warns if someone were to do CC=gcc.

further, you *cannot* write to std{out,err} ever.  some packages test the output of the compiler for feature availability and this would break it (we've seen this before with wrappers, and even the sandbox itself).

[Comment 12 Sam James 2022-03-05 07:29:21 UTC]

*** Bug 684894 has been marked as a duplicate of this bug. ***

[Comment 13 Sam James 2022-03-05 07:30:12 UTC]

From bug 684894:
(In reply to Patrick McLean from comment #0)
> We could easily catch ebuilds that don't respect CC (and LD and other system
> programs) by adding shell scripts (or a single script with a bunch of
> symlinks) to portage's PATH that record when they are called. then exec the
> "proper" program (like "cc" would 'exec "${CC}"''. If the scripts ever get
> called during a phase, then we could trigger a QA warning for that phase.
> 
> The standard portage install should include wrappers for all common programs
> that build systems often call that should be overridden.
> 
> We could even make a FEATURE (say call it strict-progs) that makes these
> shell scripts simply "exit 1" so the build will fail if a package doesn't
> respect one of the program variables. Developers could be encouraged to
> enable this feature so they catch any ebuilds that aren't respecting
> variables such as CC.