boringssl/tool/CMakeLists.txt

include_directories(../include)

add_executable(
  bssl

  args.cc
  client.cc
  const.cc
  digest.cc
  pkcs12.cc
  rand.cc
  server.cc
  speed.cc
  tool.cc
  transport_common.cc
)

if (APPLE OR WIN32)
  target_link_libraries(bssl ssl crypto)
else()
  target_link_libraries(bssl ssl crypto -lrt)
endif()
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.) 2014-06-20 20:00:00 +01:00			`include_directories(../include)`

			`add_executable(`
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f \| xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac 2015-01-29 00:37:10 +00:00			`bssl`
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.) 2014-06-20 20:00:00 +01:00
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f \| xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac 2015-01-29 00:37:10 +00:00			`args.cc`
			`client.cc`
			`const.cc`
			`digest.cc`
			`pkcs12.cc`
tool: add rand. The rand subcommand outputs entropy to stdout. Change-Id: I95c2769a1784a8dd4c21efc15009080006d51349 Reviewed-on: https://boringssl-review.googlesource.com/4325 Reviewed-by: Adam Langley <agl@google.com> 2015-04-13 19:04:15 +01:00			`rand.cc`
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f \| xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac 2015-01-29 00:37:10 +00:00			`server.cc`
			`speed.cc`
			`tool.cc`
			`transport_common.cc`
Inital import. Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.) 2014-06-20 20:00:00 +01:00			`)`

Get bssl tool building on Windows. This lets us run bssl speed at least. bssl client is currently compiled out until we clean up our socket story on Windows and get it working. Change-Id: Ib1dc0d0e0a6eed7544207e7bbe138503731fda67 Reviewed-on: https://boringssl-review.googlesource.com/2103 Reviewed-by: Adam Langley <agl@google.com> 2014-10-31 20:01:29 +00:00			`if (APPLE OR WIN32)`
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f \| xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac 2015-01-29 00:37:10 +00:00			`target_link_libraries(bssl ssl crypto)`
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a \| less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427 2014-06-24 19:15:12 +01:00			`else()`
Change CMakeLists.txt to two-space indent. find -name CMakeLists.txt -type f \| xargs sed -e 's/\t/ /g' -i Change-Id: I01636b1849c00ba918f48828252492d99b0403ac 2015-01-29 00:37:10 +00:00			`target_link_libraries(bssl ssl crypto -lrt)`
Include some build fixes for OS X. Apart from the obvious little issues, this also works around a (seeming) libtool/linker: a.c defines a symbol: int kFoo; b.c uses it: extern int kFoo; int f() { return kFoo; } compile them: $ gcc -c a.c $ gcc -c b.c and create a dummy main in order to run it, main.c: int f(); int main() { return f(); } this works as expected: $ gcc main.c a.o b.o but, if we make an archive: $ ar q lib.a a.o b.o and use that: $ gcc main.c lib.a Undefined symbols for architecture x86_64 "_kFoo", referenced from: _f in lib.a(b.o) (It doesn't matter what order the .o files are put into the .a) Linux and Windows don't seem to have this problem. nm on a.o shows that the symbol is of type "C", which is a "common symbol"[1]. Basically the linker will merge multiple common symbol definitions together. If ones makes a.c read: int kFoo = 0; Then one gets a type "D" symbol - a "data section symbol" and everything works just fine. This might actually be a libtool bug instead of an ld bug: Looking at `xxd lib.a \| less`, the __.SYMDEF SORTED index at the beginning of the archive doesn't contain an entry for kFoo unless initialised. Change-Id: I4cdad9ba46e9919221c3cbd79637508959359427 2014-06-24 19:15:12 +01:00			`endif()`