87c8a643e1
This involves more synchronization with child exits as the kernel no longer closes the pre-created pipes for free, but it works on Windows. As long as TCP_NODELAY is set, the performance seems comparable. Though it does involve dealing with graceful socket shutdown. I couldn't get that to work on Windows without draining the socket; not even SO_LINGER worked. Current (untested) theory is that Windows refuses to gracefully shutdown a socket if the peer sends data after we've stopped reading. cmd.ExtraFiles doesn't work on Windows; it doesn't use fds natively, so you can't pass fds 4 and 5. (stdin/stdout/stderr are special slots in CreateProcess.) We can instead use the syscall module directly and mark handles as inheritable (and then pass the numerical values out-of-band), but that requires synchronizing all of our shim.Start() calls and assuming no other thread is spawning a process. PROC_THREAD_ATTRIBUTE_HANDLE_LIST fixes threading problems, but requires wrapping more syscalls. exec.Cmd also doesn't let us launch the process ourselves. Plus it still requires every handle in the list be marked inheritable, so it doesn't help if some other thread is launching a process with bInheritHandles TRUE but NOT using PROC_THREAD_ATTRIBUTE_HANDLE_LIST. (Like Go, though we can take syscall.ForkLock there.) http://blogs.msdn.com/b/oldnewthing/archive/2011/12/16/10248328.aspx The more natively Windows option seems to be named pipes, but that too requires wrapping more system calls. (To be fair, that isn't too painful.) They also involve a listening server, so we'd still have to synchronize with shim.Wait() a la net.TCPListener. Then there's DuplicateHandle, but then we need an out-of-band signal. All in all, one cross-platform implementation with a TCP sockets seems simplest. Change-Id: I38233e309a0fa6814baf61e806732138902347c0 Reviewed-on: https://boringssl-review.googlesource.com/3563 Reviewed-by: Adam Langley <agl@google.com>
77 lines
2.5 KiB
Plaintext
77 lines
2.5 KiB
Plaintext
Build Prerequisites:
|
|
|
|
* CMake[1] 2.8.8 or later is required.
|
|
|
|
* Perl 5.6.1 or later is required. On Windows, Strawberry Perl and MSYS Perl
|
|
have both been reported to work.
|
|
|
|
* On Windows you currently must use Ninja[2] to build; on other platforms,
|
|
it is not required, but recommended, because it makes builds faster.
|
|
|
|
* If you need to build Ninja from source, then a recent version of
|
|
Python[3] is required (Python 2.7.5 works).
|
|
|
|
* On Windows only, Yasm[4] is required.
|
|
|
|
* A C compiler is required. On Windows, MSVC 12 (Visual Studio 2013) or later
|
|
with Platform SDK 8.1 or later are supported. Recent versions of GCC and
|
|
Clang should work on non-Windows platforms, and maybe on Windows too.
|
|
|
|
* Go[5] is required for running tests, but not for building.
|
|
|
|
Using Ninja (note the 'N' is capitalized in the cmake invocation):
|
|
|
|
mkdir build
|
|
cd build
|
|
cmake -GNinja ..
|
|
ninja
|
|
|
|
Using makefiles (does not work on Windows):
|
|
|
|
mkdir build
|
|
cd build
|
|
cmake ..
|
|
make
|
|
|
|
You usually don't need to run cmake again after changing CMakeLists.txt files
|
|
because the build scripts will detect changes to them and rebuild themselves
|
|
automatically.
|
|
|
|
Note that the default build flags in the top-level CMakeLists.txt are for
|
|
debugging - optimisation isn't enabled.
|
|
|
|
If you want to cross-compile then there are example toolchain files for 32-bit
|
|
Intel and ARM in util/. Wipe out the build directory, recreate it and run cmake
|
|
like this:
|
|
|
|
cmake -DCMAKE_TOOLCHAIN_FILE=../util/arm-toolchain.cmake -GNinja ..
|
|
|
|
If you want to build as a shared library, pass -DBUILD_SHARED_LIBS=1. On
|
|
Windows, where functions need to be tagged with "dllimport" when coming from a
|
|
shared library, define BORINGSSL_SHARED_LIBRARY in any code which #includes the
|
|
BoringSSL headers.
|
|
|
|
Known Limitations on Windows:
|
|
|
|
* Versions of cmake since 3.0.2 have a bug in its Ninja generator that causes
|
|
yasm to output warnings "yasm: warning: can open only one input file, only
|
|
the last file will be processed". These warnings can be safely ignored.
|
|
The cmake bug is http://www.cmake.org/Bug/view.php?id=15253.
|
|
|
|
* cmake can generate Visual Studio projects, but the generated project files
|
|
don't have steps for assembling the assembly language source files, so they
|
|
currently cannot be used to build BoringSSL.
|
|
|
|
[1] http://www.cmake.org/download/
|
|
|
|
[2] https://martine.github.io/ninja/
|
|
|
|
[3] https://www.python.org/downloads/
|
|
|
|
[4] http://yasm.tortall.net/
|
|
|
|
Either ensure yasm.exe is in %PATH% or configure CMAKE_ASM_NASM_COMPILER
|
|
appropriately.
|
|
|
|
[5] https://golang.org/dl/
|