Hi Jeroen,
On 5 August 2014 11:41, Jeroen Hofstee jeroen@myspectrum.nl wrote:
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.
OK let's drop it for now until we are clear what is required.
Regards, Simon