easyinstall: Add an option to compile with clang++

[uweseimet]

Compiling (optimized, non-debug) on a Pi Zero WH with an up to date bullseye (64 bit) with g++ results in internal errors or segfaults, whereas on buster (32 bit) everything is fine. With the same bullseys setup (same SD card) on a Pi 4 there are no issues, indicating that the limited hardware/memory of the Pi Zero causes problems with g++, at least with a 64 bit installation.
When using clang++ instead everything is fine. clang++ claims to use less memory, and it compiles faster than g++. The resulting binaries are working fine. This is why an option to use clang++ instead of g++ may be useful, so that clang++ is installed and make is run with "make CXX=clang++".
Alternative approach that does not require any option: Make clang++ the default compiler on Pis with bullseye and 512 MB RAM. (Using clang++ on buster does not work because it is outdated.) Maybe this should not even be optional, because clang++ may be the only working compiler anyway, and more options make easyinstall more complicated to use.
Yet another simple approach: On buster use g++, on bullseye use clang++.

[rdmark]

@uweseimet As someone not knowing the intricacies of the gcc vs. clang capabilities, are there any drawbacks to using clang over gcc?

FYI it is perfectly possible to compile RaSCSI with gcc on a Pi Zero W and Zero 2 W when running a 32 bit OS. I do this all the time. I also recall seeing discussions on Discord about using virtual memory as an option, which is of course not the fastest option.

Besides, I have found that 64 bit RaSCSI runs noticeably slower and uses more memory on my Pi Zeroes, and even on my Pi 3+. Therefore I exclusively run 32 bit OSes on my Pis again.

[uweseimet]

@rdmark The Pi uses virtual memory by default, as far as I can tell. Of course if this memory is needed because there is not enough RAM, it is not fast, but if you have a Pi like the Zero WH compiling is very slow anyway. But still, even with extensive swapping I would not expect the system/the compiler to crash, but this is what happens at least with my setup.
A 64 bit Pi is not necessarily slower, but if you have just 512 MB or so of RAM it's better to stick with 32 bit. Let's wait for the next one or two generations of Pis and I guess they won't support a 32 bit OS anymore. With 4 GB or more of memory 32 bit systems are usually not adequate anymore, and that's very likely why bullseye also exists for 64 bit.
Anyway, back to the present ;-). clang++ is not the official compiler for rascsi, but I hardly use g++ anymore for rascsi, because clang++ compiles much faster. And it seems that it needs less memory indeed, just as claimed by the authors. As it even works for my 64 bit setup on a Zero WH it should also work for a 32 bit setup. Except for buster, where the clang++ version is too old. But as buster is 32 bit only and compiing with g++ on buster works, this should not be an issue.

[uweseimet]

By the way, I don't mind at all if this ticket is rejected. It's just a suggestion for a potential resolution of compilation problems on systems with memory issues.

[rdmark]

If clang provides for faster compilation on a Pi Zero I think that alone would be a solid reason to look closer at this and potentially make this the default on Bullseye, or at least offer it as an option. The long compilation times on the Zero is something users do complain about sometimes.

I've been testing on one of my Zeros here and it does seem somewhat faster, although I haven't timed it exactly since it's still too long to be sitting in front of a terminal with a stop watch. I bet there's some kind of scripting you can do to automate this.

[uweseimet]

@rdmark There is no need for any scripting. You can simply run

time make CXX=clang++

to measure the time it takes. If I recall correctly, on my PC clang++ needs about 60% if the time required with g++. I have not compared the times on my Pi Zero. I hardly ever compile on it. Even with clang++ it is very slow.
That's why #740 is important IMO. I bet there are a lot of users who would appreciate a proper means of installation (debian package). We have seen in the past that users are reluctant to use new releases, and I guess having to compile everything is one of the reasons. Just having to run "apt update" would help a lot.

[rdmark]

@uweseimet I was testing on my Buster system, and found that apt does provide a clang-11 package, which is the same as the default clang on Bullseye. The default on Buster is clang-7 which is what the clang meta package installs for you.

I'm building rascsi on Buster with clang++-11 now and so far it seems to work. I will run some more tests and report back.

[uweseimet]

@rdmark Sounds good. In that case clang++ is an option for everybody.

@akuker Regarding the Makefile: I don't think we should make clang++ the default compiler. Something with clang++ is different when you create code metrics information. As far as I can tell gcov/lcov and maybe also the SonarCloud code metrics collection do not work anymore when using clang++. This requires additional research. For now having the option to use clang++ for those who cannot use g++ and for developers who know what they are doing should be fine. There is IMHO no need to go too far and break something.

[uweseimet]

@rdmark Do you know whether there is also an option to use a newer g++ on buster and whether there are also even newer compilers optionally available on bullseys? I'm asking because of a bug in old gcc versions we cannot use the standard C++ filesystem library everywhere because it cannot deal with files > 2 GiB. Currently we have to use a Linux specific OS API for that. If newer compilers were available everywhere there might be a way to resolve this problem.
But I would like to advise again against making clang++ the default compiler in the Makefile now. This needs more investigation regarding why getting code metrics does not seem to work anymore with clang++. If it turns out that this can be resolved and additionally the filesystem library issue is resolved this would be good news. But all this needs more investigation.

[uweseimet]

Just checked bullseye: There is clang-13. (The current version is 15, by the way.) A quick test showed that at least the non-optimized binary appears to be fine when using clang++ 13 on bullseye.
There is no clang-14 or clang-15, though ;-).

[rdmark]

@uweseimet In Buster the latest available apt package is clang-11. Do you know of bugs or other drawbacks with v11 that would stop us from standardizing on this version for now? I think we still want to support Buster for some time. From what I've seen we still have a significant userbase on that Linux version.

[uweseimet]

@rdmark I don't know for sure whether there are any bugs (I did not find any so far) and suggest that someone tests this. If there are so many users there should be some who are willing to help. I am less concerned about bugs but more about test coverage not working anymore when compiling with clang. At least on my machine gcov did not like the binaries created by clang, but without gcov there is no code analysis anymore .
Until this has been verified and fixed if required, just as you propose in #971 (comment) clang should not be the default for the Makefile, but for easyinstall it should be fine. From the ordinary user's perspective this does not make a difference, does it? They just run easyinstall just like before and that's it.
All in all switchting the compiler is just a work-around, and users on small Pis will still suffer from long build times. Let the Discord users vote on Debian packages, as suggested in #740.