On Thu, 2021-03-18 at 16:02 +0100, Damian Wrobel wrote: > ---- On Thu, 18 Mar 2021 15:31:02 +0100 Richard Purdie > <[email protected]> wrote ---- > > On Thu, 2021-03-18 at 15:23 +0100, Damian Wrobel wrote: > > > Honors the PATH[1] and other user settings like > > > system wide ccache when selecting hosttools. > > > > > > Fixes the following compilation error when compiling clang-11: > > > > > > | CMake Error at cmake/modules/CheckCompilerVersion.cmake:38 (message): > > > | Host GCC version must be at least 5.1, your version is 4.8.5. > > > | Call Stack (most recent call first): > > > | cmake/modules/CheckCompilerVersion.cmake:48 (check_compiler_version) > > > > > > on CentOS which by default has the gcc 4.8.5. However, this machine > > > has configured the gcc-7 from Developer Toolset[2] as a default one: > > > > > > $ gcc --version | head -n1 > > > gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) > > > > > > $ which gcc > > > /opt/rh/devtoolset-7/root/usr/bin/gcc > > > > > > So far, I did not find any other software which would not respect > > > this setup. > > > > > > This will also start honoring system-wide ccache configuration > > > (e.g. widely used on Fedora Linux) where the gcc is used from > > > the non-standard following location: > > > > > > $ which gcc > > > /usr/lib64/ccache/gcc > > > > > > once the user decided to install ccache package: > > > > > > $ rpm -qf /usr/lib64/ccache/gcc > > > ccache-4.2-1.fc33.x86_64 > > > > > > [1] > https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 > > > [2] https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/ > > > > > > Signed-off-by: Damian Wrobel <[email protected]> > > > --- > > > meta/classes/base.bbclass | 6 ------ > > > 1 file changed, 6 deletions(-) > > > > > > diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass > > > index b4160402f0..67b0fa1497 100644 > > > --- a/meta/classes/base.bbclass > > > +++ b/meta/classes/base.bbclass > > > @@ -131,12 +131,6 @@ def setup_hosttools_dir(dest, toolsvar, d, > fatal=True): > > > if os.path.islink(desttool): > > > os.unlink(desttool) > > > srctool = bb.utils.which(path, tool, executable=True) > > > - # gcc/g++ may link to ccache on some hosts, e.g., > > > - # /usr/local/bin/ccache/gcc -> /usr/bin/ccache, then > which(gcc) > > > - # would return /usr/local/bin/ccache/gcc, but what we need > is > > > - # /usr/bin/gcc, this code can check and fix that. > > > - if "ccache" in srctool: > > > - srctool = bb.utils.which(path, tool, executable=True, > direction=1) > > > if srctool: > > > os.symlink(srctool, desttool) > > > else: > > > > This change simply removes a different change added to work around a > different > > problem. Do we know the original issue is fixed and this can be removed? My > > worry is that we end up with a cycle of sets of patches adding and > removing > > this :(. > > > > Cheers, > > > > Richard > > > > The original patch fa764a403da34bb0ca9fa3767a9e9dba8d685965 which > introduced this functionality says: "base/bitbake.conf: Filter > contents of PATH to only allow whitelisted tools" > > So, I assuming that my patch should be fully aligned with it and in > addition it will correctly honor the order of the directories in the PATH. > > In the case where PATH is: > > PATH=/opt/rh/devtoolset-7/root/usr/bin:/usr/lib64/ccache:/usr/local/bin: > /usr/bin:/usr/local/sbin:/usr/sbin:/home/dwrobel1/.local/bin:/home/dwrobel1/bin > > it will pick-up the gcc from the first entry > "/opt/rh/devtoolset-7/root/usr/bin" > which is what the user would have expected and configured the system for.
I see I was the author of the original commit. I thought this was added as a fix for ccache issues later, I guess I'd added it as part of the original commit but it isn't mentioned in the commit message which is bad, sorry, that bit is my fault. There was more information added with: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=2e8f8d7eb330570a01c77e90540eb5e886243dbc This piece was added for a reason as we saw failures from the change originally and had to work around issues. Going from memory and the comment that was added, I think the issue is that ccache works on some systems by removing a PATH element like "/usr/lib64/ccache" in your example and expecting things to work. If the gcc in HOSTTOOLS links directly to that ccache version, the PATH trick played by these scripts does not work as the redirects end up left in PATH and we end up in loops. I don't recall which systems were playing this game with PATH but I suspect they are still around and we need to avoid these loops. Your change would revert that and break those systems. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149640): https://lists.openembedded.org/g/openembedded-core/message/149640 Mute This Topic: https://lists.openembedded.org/mt/81430061/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
