Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 427672 - Detect ignorance of CC & CXX through provision of gcc/g++ wrappers
Summary: Detect ignorance of CC & CXX through provision of gcc/g++ wrappers
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-22 19:04 UTC by Michał Górny
Modified: 2021-05-03 21:53 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Initial patch (0001-Introduce-cc-c-gcc-g-wrappers-to-catch-CC-CXX-ignora.patch,2.27 KB, patch)
2012-07-24 10:05 UTC, Michał Górny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 2012-07-22 19:09:15 UTC
what if CC="gcc -m64"?
Comment 2 Mike Gilbert gentoo-dev 2012-07-22 19:12:30 UTC
Shouldn't it be "$CHOST-gcc -m64"?
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 2012-07-22 20:03:45 UTC
ok, put differently:

CC=clang
CC=icc
Comment 5 Mike Gilbert gentoo-dev 2012-07-22 20:20:25 UTC
In that case, the gcc wrapper would not be called.
Comment 6 Fabian Groffen gentoo-dev 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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 archtester Gentoo Infrastructure gentoo-dev Security 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 gentoo-dev 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).