The -lm linker option is not known to MSVC and setting it triggers
errors in some build systems:
[6,366 / 6,367] Linking source/exe/envoy-static.exe; 11s remote
LINK : warning LNK4044: unrecognized option '/lm'; ignored
LINK : error LNK1218: warning treated as error; no output file generated
ERROR: C:/source/source/exe/BUILD:22:16: Linking of rule
'//source/exe:envoy-static' failed (Exit 4044): link.exe failed: error
executing command
Do not set -lm in case of MSVC.
clang-10 throws the following error:
In file included from external/org_brotli/c/enc/bit_cost.c:9:
external/org_brotli/c/enc/./bit_cost.h:48:16: error: implicit conversion
from 'size_t' (aka 'unsigned long') to 'double' may lose precision
[-Werror,-Wimplicit-int-float-conversion]
if (retval < sum) {
~ ^~~
1 error generated.
Make the conversion explicit.
* IMPORTANT: decoder: fix potential overflow when input chunk is >2GiB
* simplify max Huffman table size calculation
* eliminate symbol duplicates (static arrays in .h files)
* minor combing in research/ code
Otherwise libraries will not be found at runtime when installing to a
path not included in the default runtime linker's path with programs
linking brotli configured via pkg-config.
- fix formatting
- fix type conversion
- fix no-op arithmetic with null-pointer
- improve performance of hash_longest_match64
- go: detect read after close
- java decoder: support compound dictionary
- remove executable flag on non-scripts
Add an option to avoid building shared libraries (for building with EMCC)
Drive-by:
* maven: ramp up java level to minimal required
* travis: replace deprecated clang-5.0 with clang-7
* maven: fallback to jdk10 to void javadoc bug
* Verbose CLI + start pulling "Shared-Brotli"
* vesbose CLI output; fix#666
* pull `SHIFT` transforms; currently this is semantically dead code;
later it will be used by "Shared-Brotli"
Make sure the travis CI aarch32 bot tests NEON, and also that running
CROSS_COMPILE=arm-linux-gnueabihf make enables the use of NEON to
accelerate the back-reference copying.
The macro that checks for NEON support should be __ARM_NEON, not
__ARM_NEON__. [1]
AArch64 compilers define __ARM_NEON but not __ARM_NEON__.
AArch32 compilers currently seem to define both, but could be within their
rights to drop __ARM_NEON__ in future versions.
This change moves the check into the common/platform.h file, checks for
both forms, and sets BROTLI_TARGET_NEON if NEON support is available.
[1] Section 6.5.4 of the ARM C Language Extensions.
(At the time of writing, the latest version was Release 2.1.)
