diff options
author | Mohammad Akhlaghi <mohammad@akhlaghi.org> | 2020-07-02 17:56:46 +0100 |
---|---|---|
committer | Mohammad Akhlaghi <mohammad@akhlaghi.org> | 2020-07-05 15:46:32 +0100 |
commit | 1bc00c9e64bba6ebd4c90301cc2a22f25466f72f (patch) | |
tree | 0053f65c2980c714e88726aef45cc36f3827354a /reproduce/software/shell | |
parent | cedea21b101bc1a3af90f0c97b5bb768311630fd (diff) |
Only using clang in macOS systems that also have GCC
Until now, when Maneage was built on a macOS that had both a clang and GCC,
we would make links to both. But this cause many conflicts in some
high-level programs (for example Numpy and etc, all the programs where we
have explicity set 'export CC=clang' before the build recipe). This happens
because the GCC that is built on a macOS isn't complete for some
operations.
To fix this problem, when we are on a macOS, we explicity set 'gcc' to
point to 'clang' and 'g++' to point to 'clang++'. We also don't link to the
host's C-preprocessor ('cpp') on macOS systems because this is only a GNU
feature and using the GNU CPP is also known to have some basic
problems. For example this was reported by Mahdieh Nabavi (which was the
main trigger for this work):
ld: Symbol not found: ___keymgr_global
Referenced from: /Users/Mahdieh/build/software/installed/bin/cpp
Expected in: /usr/lib/libSystem.B.dylib
Also, to avoid linking to another link on the host tools (in the 'makelink'
function of 'basic.mk'), we are now using 'realpath'.
Diffstat (limited to 'reproduce/software/shell')
0 files changed, 0 insertions, 0 deletions