The bindings build was broken becaue fdb_c_performance_test failed to
link with errors of the form:
/tmp/ccym9LhK.o: In function `clearAll':
/opt/foundationdb/bindings/c/test/performance_test.c:130: undefined reference to `fdb_transaction_clear_range'
/tmp/ccym9LhK.o: In function `insertRange':
/opt/foundationdb/bindings/c/test/performance_test.c:139: undefined reference to `fdb_transaction_set'
/tmp/ccym9LhK.o: In function `singleKey':
/opt/foundationdb/bindings/c/test/performance_test.c:540: undefined reference to `fdb_transaction_set'
...
PR #901's e8f20e4 fixed this by adding `-shared` to the invocation line,
and thus doing a dynamic linking of libfdb_c.
As dynamically linking produced a working executable, this suggests that
the correct set of libraries are being linked, as the symbols can be
located eventually, just not in the right order, as the linker will
proactively not include unnecessary object files from static libraries.
And unfortunately, our performance test framework likely expects to be able
to copy the binary, and not have to worry about associated dynamically
linked libraries, so a statically linked binary is preferred.
The underlying cause of this link error is that the static library
preceeded the source code in the command line:
/usr/bin/gcc -Werror -Wno-error=format -fPIC -DNO_INTELLISENSE -fvisibility=hidden -DNDEBUG=1 -Wreturn-type -fno-omit-frame-pointer -O2 -g -Llib -lfdb_c -lpthread -Ibindings/c -o bin/fdb_c_performance_test bindings/c/test/performance_test.c
This comes from the line in the Makefile:
@$(CC) $(CFLAGS) $(fdb_c_tests_LIBS) $(fdb_c_tests_HEADERS) -o $@ bindings/c/test/performance_test.c
As we pass `-lfdb_c` before `performance_test.c`, when the linker is
considering libfdb_c.a, it sees that no symbols from any of the object
files are currently needed, and thus doesn't include them. When we
proceprocess performance_test.c, we suddenly need these symbols, but
it's too late, as the linker only processes files left-to-right.
Thus, we can resolve this problem by passing -lfdb_c after performance_test.c
Also of note is that we only seem to have this problem because the link
line was crafted by hand instead of using link-wrapper.sh, which already
does the right thing.
d076999f9b