diff options
author | Khem Raj <raj.khem@gmail.com> | 2011-11-27 17:22:37 -0800 |
---|---|---|
committer | Saul Wold <sgw@linux.intel.com> | 2011-11-29 00:20:06 -0800 |
commit | 9b13b9024d24953dedb35f62d3d8b06a29036992 (patch) | |
tree | a0d3171e1dc055ddcd78aa8fe108ee51edbccbac /meta/recipes-core | |
parent | 2278f891a9bd204d82abbd6998cf0921908f1d14 (diff) | |
download | openembedded-core-9b13b9024d24953dedb35f62d3d8b06a29036992.tar.gz openembedded-core-9b13b9024d24953dedb35f62d3d8b06a29036992.tar.bz2 openembedded-core-9b13b9024d24953dedb35f62d3d8b06a29036992.tar.xz openembedded-core-9b13b9024d24953dedb35f62d3d8b06a29036992.zip |
python-native: Fix gcc compiler detecting logic
We have a patch unixccompiler.patch where we try to throw away
everything except first element of CC string but this does not
work if gcc is prepended with something e.g. CC="ccache gcc"
then the logic fails and it ends up in some modules failing on
you silently (_sqlite3) in my case.
The fix here is to drop basename so we keep the whole
string as it is and then the detection function searches
for gcc string in the whole CC. This works in both cases
one the original intent of the patch and the second described
above. One place where it will fail is if someone has non-gcc
compiler installed in some subdir which has gcc in it e.g.
/usr/gcc/fakecc but for OE this should never happen. Ideally
the the detection logic should have tried to execute gcc
and then parsed --version output or something.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Diffstat (limited to 'meta/recipes-core')
0 files changed, 0 insertions, 0 deletions