I'm seeing the current fuzzer build fail (during `cmake`) like so:
```
-- Performing Test IS_FSANITIZE_FUZZER_NO_LINK_SUPPORTED
-- Performing Test IS_FSANITIZE_FUZZER_NO_LINK_SUPPORTED - Failed
CMake Error at cmake/AddCFlagIfSupported.cmake:17 (message):
Required flag -fsanitize=fuzzer-no-link is not supported
Call Stack (most recent call first):
fuzzers/CMakeLists.txt:6 (add_c_flag)
```
The cmake log output contains something like so:
```
/src/aflplusplus/libAFLDriver.a(aflpp_driver.o): in function `main':
aflpp_driver.c:(.text+0x11b): undefined reference to `LLVMFuzzerTestOneInput'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
I haven't figured out exactly what's happening, but I believe that
once line 5 has added `-fsanitize=fuzzer` to `CFLAGS`, future compile-
tests **also** use it during linking. This in turn pulls in the fuzzer
`main`, which expects an `LLVMFuzzerTestOneInput` symbol, and thus
fails.
Instead, just add `-fsanitize=fuzzer-no-link` to CFLAGS (as suggested
[by the documentation][libfuzzer]), and then use `-fsanitize=fuzzer`
only for linking the fuzzer targets. At least in my environment, this
results in a working fuzzer build.
[libfuzzer]: https://llvm.org/docs/LibFuzzer.html#fuzzer-usage
Currently, the DefaultCFlags.cmake overrides the
CMAKE_STATIC_LINKER_FLAGS to suppress linker warnings about files with
no symbols defined.
This has the side effect of breaking MSVC cross compilation (where
CMAKE_STATIC_LINKER_FLAGS is used to specify the /MACHINE:ARCH flag)
This commit make sure we append to CMAKE_STATIC_LINKER_FLAGS instead of
replacing its values
I tried to build my libgit2-1.9.0 package for CYGWIN but I got an error. This message appears when compiling:
[199/671] Building C object src/cli/CMakeFiles/git2_cli.dir/opt.c.o
libgit2-1.9.0/src/cli/opt.c: In function ‘cli_opt_parse’:
libgit2-1.9.0/src/cli/opt.c:564:23: warning: implicit declaration of function ‘alloca’; did you mean ‘malloc’? [-Wimplicit-function-declaration]
564 | given_specs = alloca(sizeof(const cli_opt_spec *) * (args_len + 1));
| ^~~~~~
| malloc
and later the linker emits this error message:
[668/671] Linking C executable git2.exe
FAILED: git2.exe
/usr/x86_64-pc-cygwin/bin/ld: src/cli/CMakeFiles/git2_cli.dir/opt.c.o: in function `cli_opt_parse':
/usr/src/debug/libgit2-1.9.0-1/src/cli/opt.c:564:(.text+0xce3): undefined reference to `alloca'
collect2: error: ld returned 1 exit status
The error is fixed by adding alloca.h to included headers.
Hopefully, opt.c already allows to add alloca.h for some platforms, so I just added an additional test for the preprocessor for checking if the target is CYGWIN.
Don't build docs on pushes to maint branches; those docs should only be
built _on release_. In addition, be safer about not creating an existing
branch from a tracking branch.
git's hash algorithm is sha1dc, it is not sha1. Per Linus:
> Honestly, git has effectively already moved from SHA1 to SHA1DC.
>
> So the actual known attack and weakness of SHA1 should simply not be
> part of the discussion for the next hash. You can basically say "we're
> _already_ on the second hash, we just picked one that was so
> compatible with SHA1 that nobody even really noticed.
Warn users who try to compile with SHA1 instead of SHA1DC.
Update the library's (API) version number to v1.9.0. Also update the
soname version number to 2.0, since we've had breaking ABI changes
to the library.
