In D70764#1807405, @smeenai wrote:

In D70764#1803559, @raj.khem wrote:

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.

FAILED: bin/llvm-config
...
.... -o bin/llvm-config -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.a /usr/lib/libz.so -lrt -ldl -ltinfo -lm lib/libLLVMDemangle.a
...

aarch64-yoe-linux-musl/aarch64-yoe-linux-musl-ld: /usr/lib/libz.so: error adding symbols: file in wrong format
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)

you can see that its adding /usr/lib/libz.so to linker cmdline while cross linking.

Have you set CMAKE_SYSROOT appropriately?

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.

LGTM now. I am testing it in yocto multilib SDK builds.

@AndreyChurbanov Can you push/commit this patch as well. As I dont have commit privs.

In D57529#1697029, @ostannard wrote:

A patch adding the same functionality was added back in May: D61719, rL360381.

Reviewers tend to assume that patch authors have commit access, if you don't then just say so when the patch is accepted and the reviewer will commit it for you.

@rengolin who can help committing this patch ?

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.

In D65699#1662915, @dalias wrote:

That's a separate issue of clang having a slight types-ABI mismatch with some 32-bit archs whose original ABIs used long instead of int for wchar_t. The wrong header order makes it quickly apparent, but these are independent; wrong header order is still wrong and will break (other) things even without this type mismatch. Backport of the fix would be much appreciated.

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 ?

In D65572#1614003, @compnerd wrote:

-ldl doesn't work on all platforms (e.g. android, FreeBSD, etc). -lpthread is wrong - if you want to add that, I think that we need to improve the -thread-model flag in clang first (it currently just always passes posix, which is ignored; but would identify the threading model). -lpthread is wrong - consider building on Solaris with Solaris threads rather than POSIX threads, or on Windows with the Win32 threading. This really is inline with the work that needs to be finished up with having library link dependencies for static libraries (i.e. #pragma comment(lib, …)).

In D65572#1610169, @rengolin wrote:

This is a tricky one which may vary depending on the libraries available on different systems. Which toolchain is this? Can you add more context?

Can someone with commit access push this for me please ?

Can this be backported to release_60 branch too please ?

This version works across all compilers.

@EricWF yes please. I don't have push privileges.

There is a proposed fix for glibc's assert here

@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.

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

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.

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

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.
https://chromium.googlesource.com/native_client/pnacl-libcxx/+/master%5E!/
seems to add needed tweaks which can be enabled by passing -Dmusl in CFLAGS
may be it can be backported to 3.8 branch

OK can you push this too for me please ?

In D12777#243764, @t.p.northover wrote:

Is there a bug against GAS for this? These register aliases should probably be supported there (they're mentioned in the AAPCS).

Renato, can you take a look at this for me please ?

not needed. Fixed elsewhere

Hi Renato,

Can we pull it into branch_37 as well please ?

this has been fixed by

Create a test-case as suggested