aboutsummaryrefslogtreecommitdiff
path: root/reproduce/software/config/TARGETS.conf
diff options
context:
space:
mode:
authorMohammad Akhlaghi <mohammad@akhlaghi.org>2020-07-02 17:56:46 +0100
committerMohammad Akhlaghi <mohammad@akhlaghi.org>2020-07-05 15:46:32 +0100
commit1bc00c9e64bba6ebd4c90301cc2a22f25466f72f (patch)
tree0053f65c2980c714e88726aef45cc36f3827354a /reproduce/software/config/TARGETS.conf
parentcedea21b101bc1a3af90f0c97b5bb768311630fd (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/config/TARGETS.conf')
0 files changed, 0 insertions, 0 deletions