- User Since
- Jul 10 2015, 3:44 PM (309 w, 2 d)
Sat, Jun 12
Thu, Jun 3
http://sprunge.us/FJzZXL is a file from harfbuzz and it warns
Fri, May 21
Thu, May 20
Mon, May 17
May 14 2021
Mar 25 2021
@MaskRay I dont find this in main branch yet, anything pending on me ?
Mar 24 2021
once you fix the clang-format issue reported this looks good to me.
@MaskRay how should be proceeed here
0073c293a401774ac96b4b3d27f05e13f379f98e has fixed it.
Can someone review this please?
this is because warning were disabled during cmake tests
it works with python3 too, perhaps it would be good to ask for python3 instead
Feb 25 2021
Feb 8 2021
I am still seeing build failures in NATIVE/llvm-config when I am cross building clang for say aarch64 on a x86_64 host. Even when I specify -DLLVM_ENABLE_TERMINFO=OFF, it still goes and pokes for these ncurses libs on build host and adds them to linker cmd. Since my target rootfs is set to not have these libs the final link fails to find -lterminfo rightly. Surprisingly, non NATIVE parts work ok and seem to respect LLVM_ENABLE_TERMINFO settings. Any insights ?
Feb 6 2021
Feb 4 2021
Can we get this on clang 12 release branch as well ?
Nov 17 2020
Nov 16 2020
it should have been after including syscall.h
Nov 14 2020
Add comments in source
this revision is not riscv32 specific. Let me know if this is ok
Aug 3 2020
Aug 2 2020
Fix formatting errors
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