- User Since
- Jul 10 2015, 3:44 PM (241 w, 1 d)
Jan 7 2020
Jan 3 2020
this is now in master, and I am seeing build failures in cross-building clang, e.g. when building clang for arm on a x86_64 host. its resorting to finding, libz from buildhost instead of target sysroot ( using --sysroot) and failing in link step. e.g.
Dec 28 2019
Dec 11 2019
Dec 10 2019
LGTM now. I am testing it in yocto multilib SDK builds.
Dec 4 2019
Nov 25 2019
@AndreyChurbanov Can you push/commit this patch as well. As I dont have commit privs.
Nov 23 2019
Oct 7 2019
Oct 5 2019
@rengolin who can help committing this patch ?
Sep 12 2019
somehow when doing stage2 build, it is stubborn and does not respect any of PYTHON_EXECUTABLE. PYTHON_LIBRARY or PYTHON_INCLUDE_DIR that were passed with -D on cmake invocation even after they are added to -DDCLANG_BOOTSTRAP_PASSTHROUGH list. llvm finds its own python during stage2. in stage1 it respects the above settings.
Sep 9 2019
Sep 8 2019
one issue I now see is that when we have some thing like
Can we bring this to 9.x release branch as well please ?
Aug 4 2019
Aug 1 2019
Feb 15 2019
Jan 31 2019
Aug 26 2018
Can someone with commit access push this for me please ?
May 20 2018
Can this be backported to release_60 branch too please ?
May 15 2018
May 12 2018
Apr 21 2018
Aug 16 2017
This version works across all compilers.
Aug 2 2017
@EricWF yes please. I don't have push privileges.
Jul 31 2017
There is a proposed fix for glibc's assert here
Jul 30 2017
@EricWF you are right. I have made the changes accordingly. This patch can be ignored.
@EricWF it builds fine on archlinux with this change and tests show no regressions. archlinux install right now has glibc 2.25, the xlocale.h change is committed to upcoming glibc 2.26 and newer. So I suppose it was not required all along on glibc based builds. Given this I fairly confident that we should be good with backward compatibility.
Jul 25 2017
I agree clang should not emit __ARM_FEATURE_CRC32 when -march is armv8-a it can generate it if we have march set to armv8-a+crc, there is another issue with compiler-rt build when clang is configured for multiple backends, COMPILER_RT_HAS_MCRC_FLAG macros gets defined even for x86_64 so we actually need to check for target as well.
something like below
Jul 21 2017
I agree its a clang driver problem and I did mention that in my earlier comment, this is a workaround that helps until clang is fixed and its limited to this one file.
Jul 20 2017
I think this one is better because the other patch you point to is double including locale.h which is redundant so I suggests to apply this patch
Mar 22 2017
Mar 15 2016
libcxx still has problem compiling on musl/aarch64 though. I fixed it with this patch
I think my problem was that while compiling libcxxabi, it wants to peek into libcxx headers but then libcxxabi cmake infra doesnt have the musl support like libcxx. So Now I solved it by adding -D_LIBCPP_HAS_MUSL_LIBC to CXXFLAGS.
3.8 has it in there. So may be this is just not required. I will add
-DLIBCXX_HAS_MUSL_LIBC=ON to Cmake and see what comes out
@bcraig, right, check for GLIBC can be moved after including features.h.
seems to add needed tweaks which can be enabled by passing -Dmusl in CFLAGS
may be it can be backported to 3.8 branch
Mar 14 2016
Feb 11 2016
OK can you push this too for me please ?
Sep 10 2015
Renato, can you take a look at this for me please ?
not needed. Fixed elsewhere
Jul 24 2015
Jul 15 2015
Can we pull it into branch_37 as well please ?
Jul 14 2015
this has been fixed by
Create a test-case as suggested