Inconsistent build success across pulls, probably need to track supported compiler and library versions.

[kyleaschmitt]

Before going on I should note, when it does build, things run just fine, even on an old Xeon X5675.

I run multiple linux distros and versions, and depending on the changes any given day, AND which distro/version combination, it might build cleanly or spew a ton of errors. The issue here is most likely with versioning/feature checking, but I'm unsure. This time it's from regex, but other times it's other portions: "usr/include/c++/10/bits/regex.tcc:61:26: error:..."

I haven't been formally tracking these yet, so the success rates are basically from memory:
A debian 11 box with gcc-10 seems to have about a 99% success rate.
Ubuntu 20.04 LTS with gcc-9 or gcc-10 seems to have a 50% success rate
openSUSE 15.3 with gcc-7 seems to have about a 90% success rate

Expected Behavior

The build will succeed, or at very least test if the installed compiler and libraries support the features it needs, and report what's missing.

Current Behavior

Depending on the day, a long compiler error, generally not about llama.cpp itself, but about specific c++ features.

Environment and Context

Distro	Kernel	Compiler	CPU
Debian 11	5.10.0-21-amd64	gcc version 10.2.1 20210110	Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz
Ubuntu 20.04 LTS	5.4.0-135-generic	Ubuntu 9.4.0-1ubuntu1~20.04.1	AMD Ryzen 5 2400G with Radeon Vega Graphics
Ubuntu 20.04 LTS	5.4.0-135-generic	Ubuntu 10.3.0-1ubuntu1~20.04	AMD Ryzen 5 2400G with Radeon Vega Graphics
openSUSE 15.3	5.3.18-150300.59.106-default	gcc version 7.5.0 SUSE Linux	Intel(R) Xeon(R) CPU X5675 @ 3.07GHz

Steps to Reproduce

Run multiple distros, git pull && make clean && make, on a daily basis

[sw]

Are you saying that the same revision will sometimes build and sometimes fail on the same machine with the same toolchain?

Development on this project has been quite hectic. We do have CI checks on Ubuntu 22.04, it's entirely possible that the build would fail on another environment. So my advice would be to post specific commit hashes, the environment used and the error messages you got.

[kyleaschmitt]

If a particular commit builds, it will always build on a particular system. It's just that sometimes a commit will build on one of the three, and not the others. I think. I haven't actually compared the exact commits until today when you mentioned it.

Right now cc9cee8 builds fine on the above debian and opensuse systems, but not on ubuntu 20.04. I'll try and keep track of it from now and update when it happens.

[kyleaschmitt]

Humm. I must have done something very odd on my system between the last successful build and this.
podman run -it ubuntu:20.04 /bin/bash -c 'apt update && apt install -y git build-essential && git clone https://github.com/ggerganov/llama.cpp.git && cd llama.cpp && git checkout cc9cee8 && make'

That builds just fine in a podman container on that ubuntu host. I'll update if I come across a real issue and it's not just some odd fluke.

[sw]

Closing this, please re-open if you can provide details of a build failing.

[kyleaschmitt]

I figured it out, and figured I'd share. Nothing to do with the code or even the machine, but with what I had in the source directory itself: TLDR gcc read a file from my build dir with #include <memory>, instead of the real memory header file, thus breaking everything.

I had been playing with scripts giving an agent a memory, and they stored what they wanted to remember in a file named memory in the source directory.

Due to recent advancements in C++, .h is no longer required for header files, so the empty file memory was being included.