Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/boringssl.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-09-20Don't try to setup CPUID if NO_ASM.Adam Langley
Change-Id: Idec1cda87b0a58e9350d0e10c3251a2c47ac1929 Reviewed-on: https://boringssl-review.googlesource.com/1790 Reviewed-by: Adam Langley <agl@google.com>
2014-09-12Add a CRYPTO_library_init and static-initializer-less build option.David Benjamin
Chromium does not like static initializers, and the CPU logic uses one to initialize CPU bits. However, the crypto library lacks an explicit initialization function, which could complicate (no compile-time errors) porting existing code which uses crypto/, but not ssl/. Add an explicit CRYPTO_library_init function, but make it a no-op by default. It only does anything (and is required) if building with BORINGSSL_NO_STATIC_INITIALIZER. Change-Id: I6933bdc3447fb382b1f87c788e5b8142d6f3fe39 Reviewed-on: https://boringssl-review.googlesource.com/1770 Reviewed-by: Adam Langley <agl@google.com>
2014-06-24Include some build fixes for OS X.Adam Langley
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-21Inital import.Adam Langley
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta). (This change contains substantial changes from the original and effectively starts a new history.)