In GNUmakefile.llvm, several variables are unconditionally populated
by expanding $(LLVMVER) and $(LLVM_CONFIG) inside shell commands.
However, when LLVM is not present, both those variables are empty,
meaning that the shell commands end up malformed and emit harmless, but
noisy, errors like this one:
/bin/sh: --: invalid option
Usage: /bin/sh [GNU long option] [option] ...
/bin/sh [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--pretty-print
--rcfile
--rpm-requires
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
/bin/sh: line 1: test: -gt: unary operator expected
/bin/sh: line 1: test: -lt: unary operator expected
/bin/sh: line 1: test: -ge: unary operator expected
/bin/sh: line 1: test: -ge: unary operator expected
Fix the problem by only populating the "downstream" variables if the
upstream ones have values.
* rely less on the shell and more on GNU make to parse the versions
* fixed retrieval of minor version (for 18.1.8 it gave 8 instead of 1!)
* auto-detection of llvm-config within the supported version range
* replaced backticks by `$(...)` syntax
* tested against `busybox static-sh`, `bash`, `dash` and `csh`
Adjust version check to only warn for LLVM 17.x and newer, which are the
development versions. Otherwise we'll get:
```bash
make LLVM_CONFIG=llvm-config-15 CC=clang-15 CXX=clang++-15
<snip>
GNUmakefile.llvm:69: you are using an in-development llvm version - this might break llvm_mode!
```
for versions that are supported, and not in development.
- Lifting the standard to C++17.
- Beyond the cosmetic changes, it boils down to BasicBlock::getInstList being
no longer available (and reading the header it is no accident).
Building into a DESTDIR gives circular links such as:
lrwxrwxrwx. 1 rjones rjones 17 Mar 31 18:09 /home/rjones/rpmbuild/BUILDROOT/american-fuzzy-lop-4.00c-3.git285a5cb3.fc37.x86_64/usr/lib64/afl/afl-compiler-rt.o -> afl-compiler-rt.o
I have to admit I've no idea what the original link command is trying
to achieve, but it's clearly wrong and deleting it fixes the problem.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
