Max Krasnyansky

Just wanted to mention that our CI didn't catch this issue because something changed in the build environment of the Windows Action Runners. The MSVC builld job now picks up...

> > @Dibakar I just wanted to compile with MSVC arm64, and your PR now breaks all the llama.cpp build-scripts with MSVC arm64, because you did not exclude MSVC before...

@AndreasKunar We just need to update the README using instructions from my original PR that enabled optimized builds for the X-Elite. https://github.com/ggerganov/llama.cpp/pull/7191 You can also find the overall procedure in...

> I'd rather also have the option to directly install llvm via github, without needing chocolately No objection to having options :) We should have a recommended way though, that...

Looks good to me. Re: OpenMP. @fmz and I are working on the next round of the Threadpool updates that we submitted earlier. It had to be re-written a bit...

I think it's safe to bump the Android API level to 31 at this point : https://apilevels.com/ The following build works with no additional changes with Android NDK r26b (prev...

> > I think it's safe to bump the Android API level to 31 at this point : https://apilevels.com/ > > 66.5% coverage seems low for the kind of hardware...

> Hi, @max-krasnyansky -- > > I think whichever direction is chosen depends on what kind of (best-effort) support `llama.cpp` is intended to have for Android, either towards broader device...

Ah. Ok. `GGML_STATIC=ON` is busted on Android without linking `libdl` (missing `dladdr`). So the change for `libm` is not needed (it's already linked properly), and `libdl` change looks good.

I'd say let's remote the libm change. No need for redundancy. I'd also update the CMake command with: - `ANDROID_PLATFORM=android-28` - `CMAKE_C_FLAGS="-march=armv8.7a"` - `CMAKE_CXX_FLAGS="-march=armv8.7a"` (btw ideally we should just add...