Currently, if LLD is in a weird location and has a version string like:
```bash
Ubuntu LLD 18.1.3 (compatible with GNU linkers)
```
or
```bash
Homebrew LLD 20.1.2 (compatible with GNU linkers)
```
The version comparison will fail:
```bash
GNUmakefile.llvm:247: ld.lld found in a weird location (/opt/homebrew/bin/ld.lld) and its of a different version than LLMV (LLD vs. 20.1.2) - cannot enable LTO mode
```
Fix that by replacing the usage of awk, with the same sed command used
to retrieve the version of Clang, which fixes the issue:
```bash
GNUmakefile.llvm:245: ld.lld found in a weird location (/opt/homebrew/bin/ld.lld), but its the same version as LLVM so we will allow it
```
After the llvm_mode directory was removed in 996986bed5 and compilation
started happening from the root, adding llvm_mode to the debug path is
incorrect and causes source file lookups to fail when debugging e.g.
afl-cc or the llvm pass.
`-flat_namespace` is effectively deprecated and doesn't really work as
expected these days. Omitting the `-flat_namespace` means that binaries
are built with a two-level namespace, which don't support
`-undefined suppress`.
The idiomatic way of telling the linker to look up undefined symbols at
runtime is using `-undefined dynamic_lookup`, which is supported by a
two-level namespace.
See also:
ocaml/ocaml#10723mono/mono#21257
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>
