Hello Simon,
On 05-08-14 16:47, Simon Glass wrote:
Compiler names normally end with cc, but not always gcc. So update the detection logic.
Reported-by: Jeroen Hofstee jeroen@myspectrum.nl Signed-off-by: Simon Glass sjg@chromium.org
Changes in v4:
- Add new patch to search for *cc instead of *gcc
Changes in v3: None Changes in v2: None
tools/buildman/toolchain.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py index 1b9771f..e4fcf1b 100644 --- a/tools/buildman/toolchain.py +++ b/tools/buildman/toolchain.py @@ -146,7 +146,7 @@ class Toolchains: for subdir in ['.', 'bin', 'usr/bin']: dirname = os.path.join(path, subdir) if verbose: print " - looking in '%s'" % dirname
for fname in glob.glob(dirname + '/*gcc'):
for fname in glob.glob(dirname + '/*cc'): if verbose: print " - found '%s'" % fname self.Add(fname, True, verbose)
I don't have the time to test this now, but this might have funny side affects. Since cc itself is commonly a symlink to gcc / clang etc, it will find the same compiler twice. Not sure if this is handled correctly.
In my hacky attempt to support this I also stored the actual compiler name, since it is concatenated with gcc somewhere else if I recall correctly.
Anyway, unless you are sure this works, I don't mind dropping it, for the time being. There are some more issues for e.g. FreeBSD, gcc will get installed in /usr/local/bin and carries a version number like gcc47 etc. clang on linux is just clang and there is no cc version etc.
Regards, Jeroen