kris/boringssl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
3ce3c369cb
boringssl/BUILDING

76 lines
2.6 KiB
Plaintext
Raw Normal View History

Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
Build Prerequisites:
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
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
* CMake[1] 2.8.8 or later is required.
* Perl 5.6.1 or later is required. On Windows, Strawberry Perl and MSYS Perl
Find perl using the CMake's standard FindPerl module. This gives a standard PERL_EXECUTABLE configuration knob which is useful for specifying a perl to use without having it in PATH. Change-Id: I4b196b77e0b4666081a3f291fee3654c47925844 Reviewed-on: https://boringssl-review.googlesource.com/3570 Reviewed-by: Adam Langley <agl@google.com>
2015-02-23 18:06:19 +00:00
have both been reported to work. If not found by CMake, it may be configured
explicitly by setting PERL_EXECUTABLE.
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
* 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).
Find perl using the CMake's standard FindPerl module. This gives a standard PERL_EXECUTABLE configuration knob which is useful for specifying a perl to use without having it in PATH. Change-Id: I4b196b77e0b4666081a3f291fee3654c47925844 Reviewed-on: https://boringssl-review.googlesource.com/3570 Reviewed-by: Adam Langley <agl@google.com>
2015-02-23 18:06:19 +00:00
* On Windows only, Yasm[4] is required. If not found by CMake, it may be
configured explicitly by setting CMAKE_ASM_NASM_COMPILER.
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
* A C compiler is required. On Windows, MSVC 12 (Visual Studio 2013) or later
Clean up use of Windows Platform SDK headers. Define WIN32_LEAN_AND_MEAN before including Windows Platform SDK headers to preempt naming conflicts and to make the build faster. Avoid including those headers in BoringSSL headers. Document that Platform SDK 8.1 or later is required on Windows. Change-Id: I907ada21dc722527ea37e839c71c5157455a7003 Reviewed-on: https://boringssl-review.googlesource.com/3100 Reviewed-by: Adam Langley <agl@google.com>
2015-01-28 07:06:00 +00:00
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.
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
Use TCP sockets rather than socketpairs in the SSL tests. 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>
2015-02-21 06:54:29 +00:00
* Go[5] is required for running tests, but not for building.
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
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.
Honor the standard BUILD_SHARED_LIBS cmake variable. The variable switches the default type for add_library from STATIC to SHARED. We can condition additional stuff on that for convenience. (tabtest still doesn't build.) BoringSSL as any kind of stable system shared library is still very much unsupported, but this is probably handy for making sure we don't forget all those pesky OPENSSL_EXPORTs. Change-Id: I66ab80bcddbf3724e03e85384141fdf4f4acbc2e Reviewed-on: https://boringssl-review.googlesource.com/3092 Reviewed-by: Adam Langley <agl@google.com>
2015-01-28 05:50:21 +00:00
Note that the default build flags in the top-level CMakeLists.txt are for
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
debugging - optimisation isn't enabled.
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
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:
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
cmake -DCMAKE_TOOLCHAIN_FILE=../util/arm-toolchain.cmake -GNinja ..
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
Honor the standard BUILD_SHARED_LIBS cmake variable. The variable switches the default type for add_library from STATIC to SHARED. We can condition additional stuff on that for convenience. (tabtest still doesn't build.) BoringSSL as any kind of stable system shared library is still very much unsupported, but this is probably handy for making sure we don't forget all those pesky OPENSSL_EXPORTs. Change-Id: I66ab80bcddbf3724e03e85384141fdf4f4acbc2e Reviewed-on: https://boringssl-review.googlesource.com/3092 Reviewed-by: Adam Langley <agl@google.com>
2015-01-28 05:50:21 +00:00
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.
Add visibility rules. This change marks public symbols as dynamically exported. This means that it becomes viable to build a shared library of libcrypto and libssl with -fvisibility=hidden. On Windows, one not only needs to mark functions for export in a component, but also for import when using them from a different component. Because of this we have to build with |BORINGSSL_IMPLEMENTATION| defined when building the code. Other components, when including our headers, won't have that defined and then the |OPENSSL_EXPORT| tag becomes an import tag instead. See the #defines in base.h In the asm code, symbols are now hidden by default and those that need to be exported are wrapped by a C function. In order to support Chromium, a couple of libssl functions were moved to ssl.h from ssl_locl.h: ssl_get_new_session and ssl_update_cache. Change-Id: Ib4b76e2f1983ee066e7806c24721e8626d08a261 Reviewed-on: https://boringssl-review.googlesource.com/1350 Reviewed-by: Adam Langley <agl@google.com>
2014-07-31 00:02:14 +01:00
Improve the documentation in BUILDING The initial instructions given don't work on Windows for a variety of reasons. Document the prerequisite tools and the limitations on Windows. BUG=crbug.com/451610 Change-Id: Ib5eaf00ed9b91c02b4d0e9987f8f3b4eb73266d3 Reviewed-on: https://boringssl-review.googlesource.com/3010 Reviewed-by: Adam Langley <agl@google.com>
2015-01-23 23:13:17 +00:00
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/
[5] https://golang.org/dl/
Reference in New Issue Copy Permalink