* Fix the RocksDB compile issue with clang
By default, RocksDB is using its own compile/link flags, no matter how
FDB flags are. This led to the issue that if FDB decides to use
clang/ldd/libc++, RocksDB will pick up the compiler/linker but still use
libstdc++, which is incompatible to libc++, causing Symobl Missing error
during the link stage.
With this patch, if FDB uses libc++, then the information is stored in
CMAKE_CXX_FLAGS and being forwarded to RocksDB. RocksDB will then use
libc++ and compatible with FDB.
* fixup! update the indentation
With aarch64, in the current docker image, linking curl statically doesn't work yet.
This is the diagnostic:
```
fdbclient/awssdk-build/curl/lib/strerror.c:32:6: error: #error "strerror_r MUST be either POSIX, glibc or vxworks-style"
2022-09-22 16:05:30 # error "strerror_r MUST be either POSIX, glibc or vxworks-style"
2022-09-22 16:05:30 ^~~~~
```
The root cause is that curl's cmake feature detection logic gets
confused since it can't build binaries that execute successfully with
the link flags it wants:
```
$ cc test.c -lssl
$ ./a.out
./a.out: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
```
The fdb c shim build requires python3. Let's not allow python2 to get
used there.
Otherwise we can see something like this:
```
FAILED: bindings/c/libfdb_c.so.init.c bindings/c/libfdb_c.so.tramp.S
cd /home/anoyes/workspace/foundationdb/build/bindings/c && /usr/bin/python2.7 /home/anoyes/workspace/foundationdb/contrib/Implib.so/implib-gen.py --target aarch64 --outdir /home/anoyes/workspace/foundationdb/build/bindings/c --dlopen-callback=fdb_shim_dlopen_callback /home/anoyes/workspace/foundationdb/build/lib/libfdb_c.so
File "/home/anoyes/workspace/foundationdb/contrib/Implib.so/implib-gen.py", line 27
sys.stderr.write(f'{me}: warning: {msg}\n')
```
* Don't build fdb c shim with ubsan
This avoids duplicate symbols when linking. It doesn't really make sense
to assemble files with -fsanitize=undefined anyway, since it won't
insert instrumentation.
* Consolidate boost_asan with boost_target
* Fix ASAN build
Description
-diff-2: Fix Mac build issues
-diff-1: Address review comments
Patch addresses the issue where ASAN build failed after introducing
BlobGranule compression.
Testing
ASAN build
* proof of concept
* use code-probe instead of test
* code probe working on gcc
* code probe implemented
* renamed TestProbe to CodeProbe
* fixed refactoring typo
* support filtered output
* print probes at end of simulation
* fix missed probes print
* fix deduplication
* Fix refactoring issues
* revert bad refactor
* make sure file paths are relative
* fix more wrong refactor changes
Currently, we have code in different folders like `flow/` and `fdbrpc/`
that should remain isolated. For example, `flow/` files should not
include functionality from any other modules. `fdbrpc/` files should
only be able to include functionality from itself and from `flow/`.
However, when creating a shared library, the linker doesn't complain
about undefined symbols -- this only happens when creating an
executable. Thus, for example, it is possible to forward declare an
`fdbclient` function in an `fdbrpc` file and then use it, and nothing
will break (when it should, because this is illegal).
This change adds dummy executables for a few modules (`flow`, `fdbrpc`,
`fdbclient`) that will cause a linker error if there are included
symbols which the linker can't resolve.
Andrew Noyes