Martin Storsjö
Martin Storsjö
> The current approach of using `argv[0]` would be better, though, if we would be using symlinks. E.g. it would allow us to have both `clang.exe` and `clang++.exe` be symlinks...
> This is unfortunate because a huge number of existing packages assume mingw supports -rpath. Which are these huge numbers of packages that does this? > It would be ideal...
> _Huge_ is a stretch, probably. But in particular, I've come across it when porting mingw packages under conan. The pkg-config generator there generates .pc files containing rpath (specifically when...
I posted a patch for review, for this issue now, at https://github.com/llvm/llvm-project/pull/102886.
This issue should have been fixed by the upstream fix in https://github.com/llvm/llvm-project/commit/69f76c782b554a004078af6909c19a11e3846415, which was backported to the 19.x release branch, and should be included in the latest prerelease at https://github.com/mstorsjo/llvm-mingw/releases/tag/20240820.
Hmm, weird. What distribution are you building it on? In practice, if you'd add `-DLLDB_ENABLE_CURSES=NO` in `build-llvm.sh`, or add `--disable-lldb` to the call to `build-llvm.sh` in `build-all.sh`, I would expect...
``` diff --git a/build-llvm.sh b/build-llvm.sh index ef40d3b..022ce72 100755 --- a/build-llvm.sh +++ b/build-llvm.sh @@ -283,6 +283,7 @@ cmake \ -DLLVM_TOOLCHAIN_TOOLS="llvm-ar;llvm-ranlib;llvm-objdump;llvm-rc;llvm-cvtres;llvm-nm;llvm-strings;llvm-readobj;llvm-dlltool;llvm-pdbutil;llvm-objcopy;llvm-strip;llvm-cov;llvm-profdata;llvm-addr2line;llvm-symbolizer;llvm-windres;llvm-ml;llvm-readelf" \ ${HOST+-DLLVM_HOST_TRIPLE=$HOST} \ -DLLDB_INCLUDE_TESTS=OFF \ + -DLLDB_ENABLE_CURSES=OFF \ $CMAKEFLAGS \ .....
> thanks, I will patch it locally and give feedback. > > Are you okay with me using gcc to compile? Yeah, starting the build with GCC should be totally...
> the patch makes it compile :) Thanks, that's good news. In any case, the underlying build failure of lldb on your distribution is primarily an upstream lldb bug then...
I presume you mean a toolchain hosted on aarch64-musl, but still targeting the `*-w64-mingw32` targets? That wouldn't probably be awfully complicated to add; if there is a preexisting easily used...