honggfuzz: update to 2.6

[camshaft]

cargo-bolero will now compile correctly with honggfuzz. However, it seems that building harnesses is still broken (at least on nixos):

  make: Entering directory 'lib/bolero-honggfuzz/honggfuzz'
  gcc -c -O3 -mtune=native -funroll-loops -fPIE -std=c11 -I/usr/local/include -D_GNU_SOURCE -Wall -Wextra -Werror -Wno-format-truncation -Wno-override-init -I. -D_FILE_OFFSET_BITS=64 -finline-limit=4000 -D_HF_ARCH_LINUX -g -ggdb -g3 -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0   -o libhfuzz/fetch.o libhfuzz/fetch.c
  gcc -c -O3 -mtune=native -funroll-loops -fPIE -std=c11 -I/usr/local/include -D_GNU_SOURCE -Wall -Wextra -Werror -Wno-format-truncation -Wno-override-init -I. -D_FILE_OFFSET_BITS=64 -finline-limit=4000 -D_HF_ARCH_LINUX -g -ggdb -g3 -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0   -o libhfuzz/instrument.o libhfuzz/instrument.c
  gcc -c -O3 -mtune=native -funroll-loops -fPIE -std=c11 -I/usr/local/include -D_GNU_SOURCE -Wall -Wextra -Werror -Wno-format-truncation -Wno-override-init -I. -D_FILE_OFFSET_BITS=64 -finline-limit=4000 -D_HF_ARCH_LINUX -g -ggdb -g3 -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0   -o libhfuzz/linux.o libhfuzz/linux.c
  gcc -c -O3 -mtune=native -funroll-loops -fPIE -std=c11 -I/usr/local/include -D_GNU_SOURCE -Wall -Wextra -Werror -Wno-format-truncation -Wno-override-init -I. -D_FILE_OFFSET_BITS=64 -finline-limit=4000 -D_HF_ARCH_LINUX -g -ggdb -g3 -fPIC -fno-stack-protector -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0   -o libhfuzz/memorycmp.o libhfuzz/memorycmp.c
  make: Leaving directory 'lib/bolero-honggfuzz/honggfuzz'

  --- stderr
  In file included from /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/features.h:503,
                   from /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/ctype.h:25,
                   from libhfuzz/memorycmp.c:1:
  /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/bits/string_fortified.h:77:1: error: ‘strcpy’ defined both normally and as ‘alias’ attribute
     77 | __NTH (strcpy (char *__restrict __dest, const char *__restrict __src))
        | ^~~~~
  /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/bits/string_fortified.h:128:1: error: ‘strcat’ defined both normally and as ‘alias’ attribute
    128 | __NTH (strcat (char *__restrict __dest, const char *__restrict __src))
        | ^~~~~
  /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/bits/string_fortified.h:150:1: error: ‘strlcpy’ defined both normally and as ‘alias’ attribute
    150 | __NTH (strlcpy (char *__restrict __dest, const char *__restrict __src,
        | ^~~~~
  /nix/store/fwh4fxd747m0py3ib3s5abamia9nrf90-glibc-2.39-52-dev/include/bits/string_fortified.h:167:1: error: ‘strlcat’ defined both normally and as ‘alias’ attribute
    167 | __NTH (strlcat (char *__restrict __dest, const char *__restrict __src,
        | ^~~~~
  make: *** [Makefile:307: libhfuzz/memorycmp.o] Error 1
  thread 'main' panicked at lib/bolero-honggfuzz/build.rs:26:5:
  assertion failed: status.success()
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[jtojnar]

error: ‘strcpy’ defined both normally and as ‘alias’ attribute

Looks like honggfuzz Nixpkgs package works around this by reducing hardening:

https://github.com/NixOS/nixpkgs/blob/3ac9c7a0b25a500cf799038cd4a253dc5d899c6b/pkgs/tools/security/honggfuzz/default.nix#L35

[camshaft]

I can try that. However, honggfuzz appears to be broken on old builds of bfd... (i.e. ones being used in the bolero CI). Not really sure what to do about that...

[jtojnar]

Looks like that issue might be fixed by google/honggfuzz@4c85173.