I have tested this revision and it fixes the problem I was seeing

I am getting a compiler error on clang-15, can you confirm if this will work with clang-15 too

I built this on top if 14.x branch and it fixes the problems, I was seeing and the warning is still emitted as expected.

I have submitted a github issue which seems to be related here https://github.com/llvm/llvm-project/issues/54456

rebased

@MaskRay can you help in moving this forward ?

rebased

@peter.smith Can you help landing this changeset ? there has been no objections on it thus far.

In D121379#3373679, @MaskRay wrote:

Note: powerpc64 defines __powerpc__ as well. You need to check whether powerpc64 needs this as well.

In D119590#3316050, @JonChesterfield wrote:

Cross compilers are a hazard here. I'd expect there to be a fairly long list of magic flags you need to pass to clang to get it to find the right libraries. Can you add fno-openmp-implicit-rpath to that list instead?

I tested this patch and it fixes lldb build. Thanks for taking care of this,.

In D119058#3301524, @MaskRay wrote:

Move LLVM_ENABLE_ZLIB

I verified both patches together on latest 13.x branch and it fixes the issue I was seeing. So please apply both the fixes suggested in description to 13.x branch.

In D107156#2970143, @JonChesterfield wrote:

The current trunk cmake guards whether to build this with:

if (LLVM_DIR)
  # Builds that use pre-installed LLVM have LLVM_DIR set.                                                                                                                                                          
  find_program(CLANG_TOOL clang PATHS ${LLVM_TOOLS_BINARY_DIR} NO_DEFAULT_PATH)
  find_program(LINK_TOOL llvm-link PATHS ${LLVM_TOOLS_BINARY_DIR}
    NO_DEFAULT_PATH)
  find_program(OPT_TOOL opt PATHS ${LLVM_TOOLS_BINARY_DIR} NO_DEFAULT_PATH)
  libomptarget_say("Building AMDGCN device RTL. Using clang: ${CLANG_TOOL}")
elseif (LLVM_TOOL_CLANG_BUILD AND NOT CMAKE_CROSSCOMPILING AND NOT OPENMP_STANDALONE_BUILD)
  # LLVM in-tree builds may use CMake target names to discover the tools.                                                                                                                                          
  set(CLANG_TOOL $<TARGET_FILE:clang>)
  set(LINK_TOOL $<TARGET_FILE:llvm-link>)
  set(OPT_TOOL $<TARGET_FILE:opt>)
  libomptarget_say("Building AMDGCN device RTL. Using clang from in-tree build")
else()
  libomptarget_say("Not building AMDGCN device RTL. No appropriate clang found")
  return()
endif()

standalone cross-build

Which path are you hitting? Can grep for 'Building AMDGCN device RTL' to see which.

This breaks a case where opt is used from installed locations especially in standalone cross-build environment we pass -DOPT_TOOL=${STAGING_BINDIR_NATIVE}/opt and it worked ok but now its expecting opt to be built along with openmp build and fails like below

https://reviews.llvm.org/D104788 fixes it as well.

In D104821#2837568, @kkwli0 wrote:

Does D104788 take care of it?

In D104183#2816953, @peter.smith wrote:

For ELF targets I think this should work fine. However looking at the previous change I think this may break the Darwin build. This change looks like it reverts:

commit 84610ba9b38d917317ac997074acacd99962d767
Author: Steven Wu <stevenwu@apple.com>
Date:   Sat Oct 4 00:18:59 2014 +0000

    Fix the armv7 thumb builtins on darwin

    The arm builtins converted into thumb in r213481 are not working
    on darwin. On apple platforms, .thumb_func directive is required
    to generated correct symbols for thumb functions.

    <rdar://problem/18523605>

    llvm-svn: 219040

I think we'll need a way to get .thumb_func added for Darwin or potentially call DEFINE_COMPILERRT_FUNCTION for Armv6.

In D104183#2815292, @compnerd wrote:

Some platforms (e.g. WoA) do require thumb-only compilation. Can we conditionalize this on whether we are building for ARMv6 or not?

ping,

http://sprunge.us/FJzZXL is a file from harfbuzz and it warns

In D102872#2773106, @DavidSpickett wrote:

I assume this is caused by the removal of the specific NativeRegisterContextLinux_mips and you are building lldb on MIPS but you're going to connect to another debug server (gdb, custom stub etc.).

The problem with doing it this way is then if you build on a supported platform e.g. AArch64 NativeRegisterContextLinux_arm64 we then have two copies of CreateHostNativeRegisterContextLinux. Somehow this isn't an error on my system, and it picks up the one you've added. Meaning that you can't debug a simple hello world.

See the comment in lldb/source/Plugins/Process/Linux/NativeRegisterContextLinux.h. (though again I'd have expect a hard linker error but anyway) Also the reason CI didn't fail is that lldb is disabled for both of the builds.

I can see the utility in allowing people to build at least lldb (client) on any platform. Perhaps we surround this in the #ifdef that the old mips register context used? Or modify our cmake to allow lldb-server to be disabled. (easier said than done)

LGTM

In D102535#2760944, @MaskRay wrote:

In D102535#2760911, @jrtc27 wrote:

In D102535#2760899, @MaskRay wrote:

In D102535#2760807, @jrtc27 wrote:

I view this as a bug in whatever calls the assembler; it should be passing -mno-relax, just as it needs to pass -fPIC as appropriate.

I'll use the -g analogy. clang -S -g emits debug info and leaves a .debug_line marker so that the assembler knows it needs to synthesize debug info and should not synthesize .debug_info from ELF symbols.
The assembler doesn't need -g to function.

For .option nopic, I agree it is not useful.

The two aren't comparable. Relaxation affects assembling and not code generation. Debug info affects code generation to emit all the information that's otherwise lost (the assembly doesn't have a copy of your source code...). Even PIC is more useful than .option norelax, as it affects what instructions get used to lower global addresses etc.

I think the -Wa,-mno-relax argument is justified if code generation cannot affect relaxation (which I am unsure).

Can GCC base assembly emission decisions on -mno-relax?

@MaskRay I dont find this in main branch yet, anything pending on me ?

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

this is no longer needed.

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 ?

Can we get this on clang 12 release branch as well ?

In D85095#2400738, @ldionne wrote:

I don't understand why this has its place in libc++. Shouldn't this be in glibc instead?

it should have been after including syscall.h

Add comments in source

In D85095#2279476, @apazos wrote:

Can you clarify on the errors you are talking about? Are you building LLVM libc++with glibc?
I have been building LLVM libc++ with MUSl and I do not see a build issue.

this revision is not riscv32 specific. Let me know if this is ok

Fix formatting errors

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