kc3-lang/libjpeg-turbo/CMakeLists.txt

CMakeLists.txt

Log

Author Commit Date CI Message
DRC 6002720c 2022-11-15T23:10:35 TurboJPEG: Opt. enable arithmetic entropy coding
DRC bc086c44 2022-11-15T23:38:47 Merge branch 'main' into dev
DRC eb1fd4ad 2022-11-15T23:38:19 Build: Fix typo in tjtest target
DRC 97772cba 2022-11-14T15:36:25 Merge branch 'ijg.lossless' into dev Refer to #402
DRC b5a9ef64 2022-11-13T13:00:26 Don't allow 12-bit JPEG support to be disabled In libjpeg-turbo 2.1.x and prior, the WITH_12BIT CMake variable was used to enable 12-bit JPEG support at compile time, because the libjpeg API library could not handle multiple JPEG data precisions at run time. The initial approach to handling multiple JPEG data precisions at run time (7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac) created a whole new API, library, and applications for 12-bit data precision, so it made sense to repurpose WITH_12BIT to allow 12-bit data precision to be disabled. e8b40f3c2ba187ba95c13c3e8ce21c8534256df7 made it so that the libjpeg API library can handle multiple JPEG data precisions at run time via a handful of straightforward API extensions. Referring to 6c2bc901e27b047440ed46920c4d3f0480b48268, it hasn't been possible to build libjpeg-turbo with both forward and backward libjpeg API/ABI compatibility since libjpeg-turbo 1.4.x. Thus, whereas we retain full backward API/ABI compatibility with libjpeg v6b-v8, forward libjpeg API/ABI compatibility ceased being realistic years ago, so it no longer makes sense to provide compile-time options that give a false sense of forward API/ABI compatibility by allowing some (but not all) of our libjpeg API extensions to be disabled. Such options are difficult to maintain and clutter the code with #ifdefs.
DRC bf01ed2f 2022-11-04T13:08:08 Fix build when SIMD extensions are disabled (Broken by previous commit)
DRC e8b40f3c 2022-11-01T21:45:39 Vastly improve 12-bit JPEG integration The Gordian knot that 7fec5074f962b20ed00b4f5da4533e1e8d4ed8ac attempted to unravel was caused by the fact that there are several data-precision-dependent (JSAMPLE-dependent) fields and methods in the exposed libjpeg API structures, and if you change the exposed libjpeg API structures, then you have to change the whole API. If you change the whole API, then you have to provide a whole new library to support the new API, and that makes it difficult to support multiple data precisions in the same application. (It is not impossible, as example.c demonstrated, but using data-precision-dependent libjpeg API structures would have made the cjpeg, djpeg, and jpegtran source code hard to read, so it made more sense to build, install, and package 12-bit-specific versions of those applications.) Unfortunately, the result of that initial integration effort was an unreadable and unmaintainable mess, which is a problem for a library that is an ISO/ITU-T reference implementation. Also, as I dug into the problem of lossless JPEG support, I realized that 16-bit lossless JPEG images are a thing, and supporting yet another version of the libjpeg API just for those images is untenable. In fact, however, the touch points for JSAMPLE in the exposed libjpeg API structures are minimal: - The colormap and sample_range_limit fields in jpeg_decompress_struct - The alloc_sarray() and access_virt_sarray() methods in jpeg_memory_mgr - jpeg_write_scanlines() and jpeg_write_raw_data() - jpeg_read_scanlines() and jpeg_read_raw_data() - jpeg_skip_scanlines() and jpeg_crop_scanline() (This is subtle, but both of those functions use JSAMPLE-dependent opaque structures behind the scenes.) It is much more readable and maintainable to provide 12-bit-specific versions of those six top-level API functions and to document that the aforementioned methods and fields must be type-cast when using 12-bit samples. Since that eliminates the need to provide a 12-bit-specific version of the exposed libjpeg API structures, we can: - Compile only the precision-dependent libjpeg modules (the coefficient buffer controllers, the colorspace converters, the DCT/IDCT managers, the main buffer controllers, the preprocessing and postprocessing controller, the downsampler and upsamplers, the quantizers, the integer DCT methods, and the IDCT methods) for multiple data precisions. - Introduce 12-bit-specific methods into the various internal structures defined in jpegint.h. - Create precision-independent data type, macro, method, field, and function names that are prefixed by an underscore, and use an internal header to convert those into precision-dependent data type, macro, method, field, and function names, based on the value of BITS_IN_JSAMPLE, when compiling the precision-dependent libjpeg modules. - Expose precision-dependent jinit*() functions for each of the precision-dependent libjpeg modules. - Abstract the precision-dependent libjpeg modules by calling the appropriate precision-dependent jinit*() function, based on the value of cinfo->data_precision, from top-level libjpeg API functions.
DRC 6c2bc901 2022-11-03T14:39:19 Don't allow disabling in-memory src/dest managers By default, libjpeg-turbo 1.3.x and later have enabled the in-memory source/destination manager functions from libjpeg v8 when emulating the libjpeg v6b or v7 API/ABI, which has allowed operating system distributors to provide those functions without adopting the backward-incompatible libjpeg v8 API/ABI. Prior to libjpeg-turbo 1.5.x, it made sense to allow users to disable the in-memory source/destination manager functions at build time and thus retain both backward and forward API/ABI compatibility relative to libjpeg v6b or v7. Since then, however, we have introduced several new libjpeg API functions that break forward API/ABI compatibility, so it no longer makes sense to allow the in-memory source/destination managers to be disabled. libjpeg-turbo only claims to be backward-API/ABI-compatible, i.e. to allow applications built against libjpeg or an older version of libjpeg-turbo to work properly with the current version of libjpeg-turbo.
DRC 664b64a9 2022-11-03T14:25:35 Merge branch 'main' into dev
DRC 4f7a8afb 2022-11-03T13:37:55 Build: Fix issues w/ Ninja Multi-Config generator - Fix an issue whereby a build with ENABLE_SHARED=0 could not be installed when using the Ninja Multi-Config CMake generator. - Fix an issue whereby a Windows installer could not be built when using the Ninja Multi-Config CMake generator. - Fix an issue whereby the Java regression tests failed when using the Ninja Multi-Config CMake generator. Based on: https://github.com/stilllman/libjpeg-turbo/commit/4f169deeb092a0513472b04f05f57bfe42b31ceb Closes #626
DRC 8c5e78ce 2022-11-03T11:22:50 Build: Document SO_AGE and TURBOJPEG_SO_AGE vars
DRC cb3642cb 2022-11-03T12:22:51 Bump version to 2.1.5 to prepare for new commits
DRC 8a3b0f70 2022-06-24T15:21:51 Implement 12-bit-specific error/warn/trace macros The macros in jerror.h refer to j_common_ptr, so it is unfortunately necessary to introduce a 12-bit-specific version of that header file (j12error.h) with 12-bit specific ERREXIT*(), WARNMS*(), and TRACEMS*() macros. (The message table is still shared between 8-bit and 12-bit implementations.) Fixes #607
DRC b98dabac 2022-04-27T12:38:58 Merge branch 'main' into dev
DRC d0e7c454 2022-04-18T11:34:07 Don't install libturbojpeg.pc if WITH_TURBOJPEG=0 Fixes #593
DRC 1b9edb5c 2022-03-10T23:57:11 Build: Fix 12-bit FP tests w/ 32-bit builds With x86-64 builds, the default value of FLOATTEST works with both the 8-bit-per-sample and 12-bit-per-sample flavors of the libjpeg API library. However, that is not the case with x86 builds. Thus, we need separate 8-bit-per-sample and 12-bit-per-sample FLOATTEST variables.
DRC 263386c2 2022-03-11T17:35:59 Merge branch 'main' into dev
DRC 2ee7264d 2022-03-11T17:28:36 Build: Don't set DEFAULT_FLOATTEST for x86 MSVC Newer versions of the 32-bit x86 Visual Studio compiler produce results compatible with FLOATTEST=no-fp-contract, so we can no longer intelligently set a default FLOATTEST value for that platform.
DRC a0148454 2022-03-11T10:50:47 Win: Fix build with Visual Studio 2010 (broken by 607b668ff96e40fdc749de9b1bb98e7f40c86d93) - Visual Studio 2010 apparently doesn't have the snprintf() inline function, so restore the macro that emulates that function using _snprintf_s(). - Explicitly include errno.h in strtest.c, since jinclude.h doesn't include it when building with Visual Studio.
DRC b3ae7779 2022-03-10T23:13:43 Fix in-tree builds (oops)
DRC 7fec5074 2022-03-08T12:34:11 Support 8-bit & 12-bit JPEGs using the same build Partially implements #199 This commit also implements a request from #178 (the ability to compile the libjpeg example as a standalone program.)
DRC fc562d11 2022-03-07T14:29:37 Bump version to 2.2 alpha1 ... ... to prepare for new features
DRC 607b668f 2022-02-10T11:33:49 MSVC: Eliminate C4996 warnings in API libs The primary purpose of this is to encourage adoption of libjpeg-turbo in downstream Windows projects that forbid the use of "deprecated" functions. libjpeg-turbo's usage of those functions was not actually unsafe, because: - libjpeg-turbo always checks the return value of fopen() and ensures that a NULL filename can never be passed to it. - libjpeg-turbo always checks the return value of getenv() and never passes a NULL argument to it. - The sprintf() calls in format_message() (jerror.c) could never overflow the destination string buffer or leave it unterminated as long as the buffer was at least JMSG_LENGTH_MAX bytes in length, as instructed. (Regardless, this commit replaces those calls with snprintf() calls.) - libjpeg-turbo never uses sscanf() to read strings or multi-byte character arrays. - Because of b7d6e84d6a9283dc2bc50ef9fcaadc0cdeb25c9f, wrjpgcom explicitly checks the bounds of the source and destination strings before calling strcat() and strcpy(). - libjpeg-turbo always ensures that the destination string is terminated when using strncpy(). (548490fe5e2aa31cb00f6602d5a478b068b99682 made this explicit.) Regarding thread safety: Technically speaking, getenv() is not thread-safe, because the returned pointer may be invalidated if another thread sets the same environment variable between the time that the first thread calls getenv() and the time that that thread uses the return value. In practice, however, this could only occur with libjpeg-turbo if: (1) A multithreaded calling application used the deprecated and undocumented TJFLAG_FORCEMMX/TJFLAG_FORCESSE/TJFLAG_FORCESSE2 flags in the TurboJPEG API or set one of the corresponding environment variables (which are only intended for testing purposes.) Since the TurboJPEG API library only ever passed string constants to putenv(), the only inherent risk (i.e. the only risk introduced by the library and not the calling application) was that the SIMD extensions may have read an incorrect value from one of the aforementioned environment variables. or (2) A multithreaded calling application modified the value of the JPEGMEM environment variable in one thread while another thread was reading the value of that environment variable (in the body of jpeg_create_compress() or jpeg_create_decompress().) Given that the libjpeg API provides a thread-safe way for applications to modify the default memory limit without using the JPEGMEM environment variable, direct modification of that environment variable by calling applications is not supported. Microsoft's implementation of getenv_s() does not claim to be thread-safe either, so this commit uses getenv_s() solely to mollify Visual Studio. New inline functions and macros (GETENV_S() and PUTENV_S) wrap getenv_s()/_putenv_s() when building for Visual Studio and getenv()/setenv() otherwise, but GETENV_S()/PUTENV_S() provide no advantages over getenv()/setenv() other than parameter validation. They are implemented solely for convenience. Technically speaking, strerror() is not thread-safe, because the returned pointer may be invalidated if another thread changes the locale and/or calls strerror() between the time that the first thread calls strerror() and the time that that thread uses the return value. In practice, however, this could only occur with libjpeg-turbo if a multithreaded calling application encountered a file I/O error in tjLoadImage() or tjSaveImage(). Since both of those functions immediately copy the string returned from strerror() into a thread-local buffer, the risk is minimal, and the worst case would involve an incorrect error string being reported to the calling application. Regardless, this commit uses strerror_s() in the TurboJPEG API library when building for Visual Studio. Note that strerror_r() could have been used on Un*x systems, but it would have been necessary to handle both the POSIX and GNU implementations of that function and perform widespread compatibility testing. Such is left as an exercise for another day. Fixes #568
DRC a3d4aadd 2022-02-01T12:53:28 Build: Embed version/API/(C) info in MSVC DLLs Based on: https://github.com/TheDorkKnight/libjpeg-turbo/commit/da7a18801a5c305d3f8a71b065f179f1e22b73ae Closes #576
DRC 17297239 2022-01-06T09:17:30 Eliminate non-ANSI C compatibility macros libjpeg-turbo has never supported non-ANSI C compilers. Per the spec, ANSI C compilers must have locale.h, stddef.h, stdlib.h, memset(), memcpy(), unsigned char, and unsigned short. They must also handle undefined structures.
DRC 2ce32e0f 2021-11-30T10:54:24 cjpeg: automatically compress PGM-->grayscale JPEG (regression introduced by aa7459050d7a50e1d8a99488902d41fbc118a50f) cjpeg sets cinfo.in_color_space to JCS_RGB as an "arbitrary guess." Since tjLoadImage() never uses JCS_RGB, the PGM reader should treat JCS_RGB the same as JCS_UNKNOWN. Fixes #566
Alex Xu (Hello71) 18edeff4 2021-10-02T14:26:57 Build: Set CMP0065 NEW (respect ENABLE_EXPORTS) Referring to https://cmake.org/cmake/help/latest/policy/CMP0065.html, CMake 3.3 and earlier automatically added compiler/linker flags such as -rdynamic/-export-dynamic, which caused symbols to be exported from executables. The primary purpose of this is to allow plugins loaded via dlopen() to access symbols from the calling program. libjpeg-turbo does not need this functionality, and enabling it needlessly increases the size of the libjpeg-turbo executables. Setting CMP0065 to NEW when using CMake 3.4 and later prevents CMake from automatically adding the aforementioned compiler/linker flags unless the ENABLE_EXPORTS property is set for a target (or the CMAKE_ENABLE_EXPORTS variable is set, which causes ENABLE_EXPORTS to be set for all targets.) Closes #554
DRC 129f0cb7 2021-08-25T12:07:58 Neon/AArch64: Don't put GAS functions in .rodata Regression introduced by 240ba417aa4b3174850d05ea0d22dbe5f80553c1 Closes #546
DRC 84d6306f 2021-07-27T11:02:23 Fix build w/CMake 3.14+ when CMAKE_SYSTEM_NAME=iOS Closes #539
DRC 5135c2e2 2021-05-28T12:51:53 Build: Use PIC for jsimd_none.o in shared libs In theory, all objects that will be included in a Un*x shared library must be built using PIC. In practice, most compilers don't require PIC to be explicitly specified for jsimd_none.o, either because the compiler automatically enables PIC in all cases (Ubuntu) or because the size of the generated object is too small. But some rare compilers do require PIC to be explicitly specified for jsimd_none.o. Fixes #520
DRC 3932190c 2021-05-17T13:05:16 Fix build w/ non-GCC-compatible Un*x/Arm compilers Regression introduced by d2c407995992be1f128704ae2479adfd7906c158 Closes #519
DRC 4f51f36e 2021-04-23T11:42:40 Bump version to 2.1.0 to prepare for final release
DRC 2f9e8a11 2021-03-29T18:54:12 OSS-Fuzz integration This commit integrates OSS-Fuzz targets directly into the libjpeg-turbo source tree, thus obsoleting and improving code coverage relative to Google's OSS-Fuzz target for libjpeg-turbo (previously available here: https://github.com/google/oss-fuzz). I hope to eventually create fuzz targets for the BMP, GIF, and PPM readers as well, which would allow for fuzz-testing compression, but since those readers all require an input file, it is unclear how to build an efficient fuzzer around them. It doesn't make sense to fuzz-test compression in isolation, because compression can't accept arbitrary input data.
DRC e795afc3 2021-03-25T22:36:15 SSE2: Fix prog Huff enc err if Sl%32==0 && Al!=0 (regression introduced by 16bd984557fa2c490be0b9665e2ea0d4274528a8) This implements the same fix for jsimd_encode_mcu_AC_refine_prepare_sse2() that a81a8c137b3f1c65082aa61f236aa88af61b3ad4 implemented for jsimd_encode_mcu_AC_first_prepare_sse2(). Based on: https://github.com/MegaByte/libjpeg-turbo/commit/1a59587397150c9ef9dffc5813cb3891db4bc0c8 https://github.com/MegaByte/libjpeg-turbo/commit/eb176a91d87a470bf8c987be786668aa944dd1dd Fixes #509 Closes #510
Adrian Bunk 2c01200c 2021-03-15T19:56:53 Build: Fix incorrect regexes w/ if(...MATCHES...) "arm*" as a regex means 'ar' followed by zero or more 'm' characters, which matches 'parisc' and 'sparc64' as well.
DRC 8a2cad02 2021-01-21T10:51:49 Build: Handle CMAKE_OSX_ARCHITECTURES=(i386|ppc) We don't officially support i386 or PowerPC Mac builds of libjpeg-turbo anymore, but they still work (bearing in mind that PowerPC builds require GCC v4.0 in Xcode 3.2.6, and i386 builds require Xcode 9.x or earlier.) Referring to #495, apparently MacPorts needs this functionality.
DRC 399aa374 2021-01-19T12:25:11 Build: Support CMAKE_OSX_ARCHITECTURES ... as long as it contains only a singular value, which must equal "x86_64" or "arm64". Refer to #495
DRC 3e8911aa 2021-01-11T13:56:01 Build: Use correct SIMD exts w/VStudio IDE + Arm64 When configuring a Visual Studio IDE build and passing -A arm64 to CMake, CMAKE_SYSTEM_PROCESSOR will be amd64, so we should set CPU_TYPE based on the value of CMAKE_GENERATOR_PLATFORM rather than the value of CMAKE_SYSTEM_PROCESSOR.
DRC cfc7e6e5 2020-11-25T14:10:55 Bump revision to 2.0.91 for post-beta fixes
DRC 8cf6f716 2020-11-24T21:32:48 Bump revision to 2.0.90 to prepare for beta
Jonathan Wright eb14189c 2020-11-17T12:48:49 Fix Neon SIMD build issues with Visual Studio - Use the _M_ARM and _M_ARM64 macros provided by Visual Studio for compile-time detection of Arm builds, since __arm__ and __aarch64__ are only present in GNU-compatible compilers. - Neon/intrinsics: Use the _CountLeadingZeros() and _CountLeadingZeros64() intrinsics provided by Visual Studio, since __builtin_clz() and __builtin_clzl() are only present in GNU-compatible compilers. - Neon/intrinsics: Since Visual Studio does not support static vector initialization, replace static initialization of Neon vectors with the appropriate intrinsics. Compared to the static initialization approach, this produces identical assembly code with both GCC and Clang. - Neon/intrinsics: Since Visual Studio does not support inline assembly code, provide alternative code paths for Visual Studio whenever inline assembly is used. - Build: Set FLOATTEST appropriately for AArch64 Visual Studio builds (Visual Studio does not emit fused multiply-add [FMA] instructions by default for such builds.) - Neon/intrinsics: Move temporary buffer allocation outside of nested loops. Since Visual Studio configures Arm builds with a relatively small amount of stack memory, attempting to allocate those buffers within the inner loops caused a stack overflow. Closes #461 Closes #475
DRC 292d78e7 2020-11-16T15:28:02 Merge branch 'master' into dev
DRC 88bf1d16 2020-11-16T14:38:15 Build: Set FLOATTEST more intelligently The "32bit" vs. "64bit" floating point test results actually have nothing to do with the FPU. That was a fallacious assumption based on the observation that, with multiple CPU types, 32-bit and 64-bit builds produce different floating point test results. It seems that this is, in fact, due to differing compiler behavior-- more specifically, whether fused multiply-add (FMA) instructions are used to combine multiple floating point operations into a single instruction ("floating point expression contraction".) GCC does this by default if the target supports FMA instructions, which PowerPC and AArch64 targets both do. Fixes #468
DRC 8f830598 2020-11-13T15:21:26 Merge branch 'master' into dev
DRC 33859880 2020-11-13T12:12:47 Neon: Auto-detect compiler intrinsics completeness This allows the Neon intrinsics code to be built successfully (albeit likely with reduced run-time performance) with Xcode 5.0-6.2 (iOS/AArch64) and Android NDK < r19 (AArch32). Note that Xcode 5.0-6.2 will not build the Armv8 GAS code without gas-preprocessor.pl, and no version of Xcode will build the Armv7 GAS code without gas-preprocessor.pl, so we always use the full Neon intrinsics implementation by default with macOS and iOS builds. Auto-detecting the completeness of the compiler's set of Neon intrinsics also allows us to more intelligently set the default value of NEON_INTRINSICS, based on the values of HAVE_VLD1*. This is a reasonable, albeit imperfect, proxy for whether a compiler has a full and optimal set of Neon intrinsics. Specific notes: - 64-bit RGB-to-YCbCr color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer forward DCT uses vld1_s16_x3(), regresses with GCC - 64-bit Huffman encoding uses vld1q_u8_x4(), regresses with GCC - 64-bit YCbCr-to-RGB color conversion does not use any of the intrinsics in question, regresses with GCC - 64-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 64-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. - 32-bit RGB-to-YCbCr color conversion: uses vld1_u16_x2(), regresses with GCC - 32-bit accurate integer forward DCT uses vld1_s16_x3(), regression irrelevant because there was no previous implementation - 32-bit accurate integer inverse DCT uses vld1_s16_x3(), regresses with GCC - 32-bit fast integer inverse DCT does not use any of the intrinsics in question, regresses with GCC - 32-bit 4x4 inverse DCT uses vld1_s16_x3(). I did not test this algorithm in isolation, so it may in fact regress with GCC, but the regression may be hidden by the speedup from the new SIMD-accelerated upsampling algorithms. Presumably when GCC includes a full and optimal set of Neon intrinsics, the HAVE_VLD1* tests will pass, and the full Neon intrinsics implementation will be enabled automatically.
DRC 3e9e7c70 2020-11-11T17:54:06 Fix build if WITH_12BIT==1 && WITH_JPEG(7|8)==1 Fixes #466
Jonathan Wright ba52a3de 2018-07-19T18:46:24 Neon: Intrinsics impl of h2v1 & h2v2 merged upsamp There was no previous GAS implementation. This commit also reverts 40557b23015d2f8b576420231b8dd1f39f2ceed8 and 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57. 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57 was only necessary because there was no Neon implementation of merged upsampling/color conversion, and 40557b23015d2f8b576420231b8dd1f39f2ceed8 was only necessary because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57.
Jonathan Wright 2acfb93c 2019-05-08T15:43:26 Neon: Intrinsics impl. of h1v2 fancy upsamling There was no previous GAS implementation.
Jonathan Wright 4f2216b4 2019-11-26T18:14:33 Neon: Intrinsics implementation of RGB->YCbCr The previous AArch32 and AArch64 GAS implementations are retained by default when using GCC, in order to avoid a performance regression. The intrinsics implementation can be forced on or off using a new NEON_INTRINSICS CMake variable.
DRC c7dd1912 2020-11-08T15:15:02 Merge branch 'master' into dev
DRC 40557b23 2020-11-06T18:51:55 Build: Fix test failures w/ Arm Neon SIMD exts Regression caused by a46c111d9f3642f0ef3819e7298846ccc61869e0 Because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, which was introduced in libjpeg-turbo 1.5.1 in response to #81, merged upsampling/ color conversion is disabled on platforms that have SIMD-accelerated YCbCr -> RGB color conversion but not SIMD-accelerated merged upsampling/color conversion. This was intended to improve performance with the Neon SIMD extensions, since those are the only SIMD extensions for which those circumstances apply. Under normal circumstances, the separate "plain" (non-fancy) upsampling and color conversion routines will produce bitwise-identical output to the merged upsampling/color conversion routines, but that is not the case when skipping scanlines starting at an odd-numbered scanline. The modified test introduced in a46c111d9f3642f0ef3819e7298846ccc61869e0 does precisely that in order to validate the fixes introduced in 9120a247436e84c0b4eea828cb11e8f665fcde30 and a46c111d9f3642f0ef3819e7298846ccc61869e0. Because of 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, the segfault fixed in 9120a247436e84c0b4eea828cb11e8f665fcde30 and a46c111d9f3642f0ef3819e7298846ccc61869e0 didn't affect the Neon SIMD extensions, so this commit effectively reverts the test modifications in a46c111d9f3642f0ef3819e7298846ccc61869e0 when using those SIMD extensions. We can get rid of this hack, as well as 7723d7f7d0aa40349d5bdd1fbe4f8631fd5a2b57, once a Neon implementation of merged upsampling/color conversion is available.
DRC 59352195 2020-10-19T21:17:46 Merge branch 'master' into dev
DRC f7ca3c5a 2020-10-19T15:34:03 Build: Improve Arm 32-bit cross-comp./packaging - Set CPU_TYPE=arm if performing a 32-bit build on an AArch64 system. This eliminates the need to use a CMake toolchain file. - Set RPMARCH=armv7hl if building on a 32-bit Arm system with an FPU. - Set RPMARCH=armv7hl and DEBARCH=armhf if performing a 32-bit build using a gnueabihf toolchain. - If performing a 32-bit Arm build, generate a 32-bit supplementary DEB package for AArch64 systems.
DRC b8200c66 2019-03-08T11:57:54 Build: Add CMake package config files Based on: https://github.com/hjmallon/libjpeg-turbo/commit/d34b89b41134bd2b581e222514ee493594193d87 Closes #339 Closes #342
DRC fe79f56b 2020-07-28T15:09:00 Merge branch 'master' into dev
DRC a46c111d 2020-07-27T14:21:23 Further jpeg_skip_scanlines() fixes - Introduce a partial image decompression regression test script that validates the correctness of jpeg_skip_scanlines() and jpeg_crop_scanlines() for a variety of cropping regions and libjpeg settings. This regression test catches the following issues: #182, fixed in 5bc43c7821df982f65aa1c738f67fbf7cba8bd69 #237, fixed in 6e95c08649794f5018608f37250026a45ead2db8 #244, fixed in 398c1e9acc9b4531edceb3d77da0de5744675052 #441, fully fixed in this commit It does not catch the following issues: #194, fixed in 773040f9d949d5f313caf7507abaf4bd5d7ffa12 #244 (additional segfault), fixed in 9120a247436e84c0b4eea828cb11e8f665fcde30 - Modify the libjpeg-turbo regression test suite (make test) so that it checks for the issue reported in #441 (segfault in jpeg_skip_scanlines() when used with 4:2:0 merged upsampling/color conversion.) - Fix issues in jpeg_skip_scanlines() that caused incorrect output with h2v2 (4:2:0) merged upsampling/color conversion. The previous commit fixed the segfault reported in #441, but that was a symptom of a larger problem. Because merged 4:2:0 upsampling uses a "spare row" buffer, it is necessary to allow the upsampler to run when skipping rows (fancy 4:2:0 upsampling, which uses context rows, also requires this.) Otherwise, if skipping starts at an odd-numbered row, the output image will be incorrect. - Throw an error if jpeg_skip_scanlines() is called with two-pass color quantization enabled. With two-pass color quantization, the first pass occurs within jpeg_start_decompress(), so subsequent calls to jpeg_skip_scanlines() interfere with the multipass state and prevent the second pass from occurring during subsequent calls to jpeg_read_scanlines().
DRC 7d829bfa 2020-07-07T10:16:29 Bump version to 2.0.6 to prepare for new commits
DRC aecee256 2020-06-19T00:03:51 Merge branch 'master' into dev
DRC ae87a958 2020-06-16T13:52:39 TurboJPEG: Make global error handling thread-safe ... on platforms that support thread-local storage. This currently includes all supported platforms except 32-bit macOS. Fixes #396
DRC 70040cb7 2020-06-02T15:05:43 Merge branch 'master' into dev
Andrew Childs a2291b25 2020-05-05T14:38:39 Build: Add missing jpegtran-icc test dependency The jpegtran-icc test must run after the cjpeg-rgb-islow test, since the latter generates testout_rgb_islow.jpg.
DRC ecf5f9a9 2020-02-18T10:43:23 Bump version to 2.0.5; Document previous commit
DRC 00d48d7e 2020-02-17T18:14:10 Merge branch 'master' into dev
DRC 044c22e1 2020-02-17T13:41:26 Test: Honor CMAKE_CROSSCOMPILING_EMULATOR variable This CMake variable is intended to define a wrapper program for executing cross-compiled executables. However, CTest doesn't use CMAKE_CROSSCOMPILING_EMULATOR, because it isn't obvious which tests should be executed with the wrapper and which tests are scripts that don't need it. This commit manually prepends ${CMAKE_CROSSCOMPILING_EMULATOR} to all unit test command lines that execute a program built by the libjpeg-turbo build system. Thus, one can set CMAKE_CROSSCOMPILING_EMULATOR in a CMake toolchain file to (for instance) "qemu-{architecture} {qemu_arguments}") in order to execute all eligible unit tests using QEMU.
DRC 9a2cf323 2020-02-11T13:41:43 Build: Enable separate iOS pkg/DMG w/ sim support Refer to #406
DRC 163f0b19 2019-10-22T19:39:38 Bump version to 2.0.4 to prepare for new commits
DRC b4110b65 2019-09-04T18:58:12 Merge branch 'master' into dev
DRC ded5a504 2019-08-15T13:24:25 tjDecodeYUV*: Fix err if TJ inst used for prog dec If the TurboJPEG instance passed to tjDecodeYUV[Planes]() was previously used to decompress a progressive JPEG image, then we need to disable the progressive decompression parameters in the underlying libjpeg instance before calling jinit_master_decompress(). This commit also modifies the build system so that the "tjtest" target will test for this issue, and it corrects a previous oversight in the build system whereby tjbenchtest did not test progressive compression/decompression unless WITH_JAVA was true.
DRC 8ef53b10 2019-08-14T22:08:59 Merge branch 'master' into dev
DRC a81a8c13 2019-08-14T13:17:11 SSE2 SIMD: Fix prog Huffman enc. error if Sl%16==0 (regression introduced by 5b177b3cab5cfb661256c1e74df160158ec6c34e) The SSE2 implementation of progressive Huffman encoding performed extraneous iterations when the scan length was a multiple of 16. Based on: https://github.com/rouault/libjpeg-turbo/commit/bb7f1ef98305da915e581b59bd0ec2ef7bdb8468 Fixes #335 Closes #367
DRC 7fbfe29c 2019-07-18T15:18:27 Merge branch 'master' into dev
DRC f37b7c1f 2019-07-02T11:28:26 Build: Fix build/install with Xcode IDE Closes #355
DRC 58a3975e 2019-04-10T14:35:45 Bump version to 2.0.3 to prepare for new commits
DRC a9075a17 2019-02-12T13:42:57 Merge branch 'master' into dev
DRC 75be88cf 2019-02-11T13:10:09 Build: Optionally install PDB files for MSVC DLLs Based on https://github.com/Youw/libjpeg-turbo/commit/333a36ae984a52e547ddeb23848873d3cc798047 Closes #329 Closes #324
DRC 674343ab 2019-01-31T15:30:25 Merge branch 'master' into dev
DRC 2d0b675a 2019-01-25T16:46:02 Build: Fix install of static build w/ VStudio IDE Unfortunately, this hack is necessary because: - install(TARGETS, ...) doesn't support the RENAME option. - We can't modify OUTPUT_NAME for the "-static" targets without breaking the regression tests. - ${CMAKE_CFG_INTDIR} doesn't seem to work properly in an install() command. Refer to #307
DRC 01e30323 2019-01-23T14:58:24 Eliminate support for compilers w/o unsigned char libjpeg-turbo has never really supported such compilers, since (AFAIK) they are non-existent on any modern computing platform and thus impossible for us to test. (Also, the TurboJPEG API would break without unsigned chars.) Furthermore, the unified CMake-based build system introduced in 2.0 always defines HAVE_UNSIGNED_CHAR, so retaining other code paths is pointless. Eliminating support for compilers without unsigned char eliminates the need for the GETJSAMPLE() macro, which improves the readability of many parts of the code as well as improving the performance of writing Targa and Windows BMP files. Fixes #317
DRC 42d62bf1 2019-01-23T11:20:11 Merge branch 'master' into dev
Orivej Desh ce90ab5d 2019-01-21T22:56:56 Build: Fix regression test failure w/ ctest -j The djpeg rgb-islow-icc-cmp test must run after the djpeg rgb-islow test, since the latter generates testout_rgb_islow.icc.
DRC 12f3d0be 2019-01-01T21:52:21 Merge branch 'master' into dev
DRC c868e41b 2019-01-01T14:26:48 Build: Fix regr. that nuked RPATH in Mac/iOS build Caused by 950580eb0c020598a4c6c8aa46c86e31062e1ddc. Since the code that sets CMAKE_INSTALL_RPATH now depends on ENABLE_SHARED, that code needed to be moved to after the point at which ENABLE_SHARED is defined.
DRC 0696b0a4 2019-01-01T13:55:01 Bump version to 2.0.2 to prepare for new commits
DRC 43ce78e0 2018-11-15T11:54:20 Build: Fix issue with HAVE_MAPFILE test on Solaris We have to link the test code into a shared library, or else the mapfile prevents necessary libc symbols from being exposed.
DRC 2cc4f93c 2018-11-12T14:40:19 Merge branch 'master' into dev
DRC 950580eb 2018-11-12T11:22:07 Build: Fix install error with fully static build Closes #273
DRC 504a295c 2018-10-11T15:13:34 Include .pc files in LJT SDKs for Visual C++ These are apparently useful in certain esoteric build environments. Closes #296
DRC 133e4af0 2018-09-04T16:56:22 Add x32 ABI support on Linux The x32 ABI is similar to the x86-64 ABI but uses 32-bit pointers. (Refer to https://sites.google.com/site/x32abi) Based on: https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/8da8fc5213d87336d6c7200aaeeca925603e12cf https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/1e33dfea8042230e266b453f53d69a6e37b7f0de https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/24ffea78da0f18d0d467d16e02dfb903e6c0181e https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/dedcf76753c8913ef5c3c6e4ea329d29494b6065 https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/d04228a7b58b9aed5bcbec383630ec1a14a3c9ca https://github.com/libjpeg-turbo/libjpeg-turbo/pull/274/commits/b4ad38316ae1899c8a00b6568bb0325d82edcd7a Closes #274
DRC 995eb29d 2018-09-04T16:57:52 Bump version to 2.1 alpha1 (to prepare for new features)
DRC a861cc2f 2018-08-31T12:54:09 Bump version to 2.0.1 to prepare for new commits
DRC ad6c3161 2018-07-25T11:03:20 Bump revision to 2.0.0
DRC 8d95be3a 2018-07-24T21:16:00 Build: Don't use @rpath with OS X 10.4 builds @rpath is only supported with 10.5 and later deployment targets. libjpeg-turbo hasn't supported 10.4 "Tiger" since prior to 1.4, but I still sometimes use the 10.4 SDK to test PowerPC code in a Snow Leopard VM.
DRC 0fa7850a 2018-07-20T11:30:04 Build: Preserve CMake exe suffix from cmd line Normally the value of CMAKE_EXECUTABLE_SUFFIX is clobbered by project(). This allows for specifying an executable suffix of .html with Emscripten builds, which causes Emscripten to build standalone HTML versions of the libjpeg-turbo test programs.
DRC 0c8eb5b4 2018-07-19T17:01:42 Honor CMake exe suffix when inst. static builds This specifically allows an Emscripten (WASM) static build (for which CMAKE_EXECUTABLE_SUFFIX=.js) to be properly installed.
DRC 34e9d7e3 2018-04-26T17:33:52 Bump revision to 1.5.91 for post-beta fixes
DRC 13e4803e 2018-03-31T16:19:01 Fix build errors when C flags include -Werror Instructing the compiler to treat warnings as errors caused some of the compiler tests to fail, because the test code was not 100% clean. Note that we now use check_symbol_exists() to check for memset() and memcpy(), since the test code for check_function_exists() produces a compiler warning due to not including <string.h>.
DRC a74655af 2018-03-31T15:34:23 CMakeLists.txt: Move intrin.h header check It is more readable for this to be next to the __builtin_ctzl() check, since both are used by the accelerated progressive Huffman code.
DRC c80ddef7 2018-03-23T23:17:08 Build: Fix rpath in iOS shared libraries When attempting to configure an iOS/ARM build with Xcode 7.2 and CMake 2.8.12, I got the following errors: CMake Error at CMakeLists.txt:560 (add_library): Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being set. This could be because you are using a Mac OS X version less than 10.5 or because CMake's platform configuration is corrupt. (x 3) CMake Error at sharedlib/CMakeLists.txt:38 (add_library): Attempting to use MACOSX_RPATH without CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG being set. This could be because you are using a Mac OS X version less than 10.5 or because CMake's platform configuration is corrupt. (x 3) Upgrading to CMake 3.x (tried 3.0 and 3.1) got rid of the errors, but the resulting shared libs still did not use @rpath as expected. Note also that CMake 3.x (at least the two versions I tested) does not automatically set the MACOSX_RPATH property as claimed. I could find nothing in the release notes for later CMake releases to indicate that either problem has been fixed. What I did find was this little nugget of code in the Darwin platform module: https://github.com/Kitware/CMake/blob/f6b93fbf3ae00a9157af2f6497bed074d585cea9/Modules/Platform/Darwin.cmake#L33-L36 This sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG="-Wl,-rpath," only if you are running OS X 10.5 or later. It makes no such check for iOS, perhaps because shared libraries aren't much of a thing with iOS apps. In any event, this commit simply sets CMAKE_SHARED_LIBRARY_RUNTIME_C_FLAG if it isn't set already, and that fixes all of the aforementioned problems.
DRC e15a6b4e 2018-03-23T11:14:50 Include .pc and man files in MinGW install[er]s These files are potentially useful to MinGW users, since MSYS2 MinGW environments have a man command by default and provide an easy way to install pkg-config. Closes #223
DRC 1095b822 2018-03-22T16:08:25 Bump revision to 1.5.90 to prepare for beta
kmx.io     mail     discord kmxgit v0.4.0