kc3-lang/libjpeg-turbo/BUILDING.md

BUILDING.md

Branch

Log

Author Commit Date CI Message
DRC be7a0c8b 2024-12-11T12:25:16 Build: Make Mac packaging architecture-agnostic Rename the ARMV8_BUILD CMake variable to SECONDARY_BUILD, and modify the makemacpkg script so that it allows any architecture in a primary or secondary build. The idea is that Apple Silicon users can package an arm64 primary build and a secondary x86_64 build, and Intel users can package an x86_64 primary build and a secondary arm64 build, using the same procedure. Also simplify the iOS build instructions, using the CMAKE_OSX_ARCHITECTURES variable rather than a toolchain.
DRC eb753630 2024-08-31T16:50:08 Update URLs - Eliminate unnecessary "www." - Use HTTPS. - Update Java, MSYS, tdm-gcc, and NSIS URLs. - Update URL and title of Agner Fog's assembly language optimization manual. - Remove extraneous information about MASM and Borland Turbo Assembler and outdated NASM URLs from the x86 assembly headers, and mention Yasm.
DRC 3202feb0 2024-02-29T16:10:20 x86-64 SIMD: Support CET if C compiler enables it - Detect at configure time, via the __CET__ C preprocessor macro, whether the C compiler will include either indirect branch tracking (IBT) or shadow stack support, and define a NASM macro (__CET__) if so. - Modify the x86-64 SIMD code so that it includes appropriate endbr64 instructions (to support IBT) and an appropriate .note.gnu.property section (to support both IBT and shadow stack) when __CET__ is defined. Closes #350
DRC 5a2353c2 2024-01-22T14:07:55 GNUInstallDirs.cmake: Various improvements - Integrate https://github.com/Kitware/CMake/commit/c07bba27302960fc2f35b6a9e00eab8b32ca9a49#diff-1e2deb5301e9481203102fcddd1b2d0d2bf0ddc1cbb445c7f4b6414a3b869ce8 so that the default man directory is <CMAKE_INSTALL_PREFIX>/share/man on FreeBSD systems. - For good measure, integrate https://github.com/Kitware/CMake/commit/f835f189aeb38a791ad09ba5c2d89300a3fd16f1 so that the default info directory is <CMAKE_INSTALL_PREFIX>/share/info on FreeBSD systems, even though we don't use that directory. - Automatically set the CMake variable type to PATH for any user-specified CMAKE_INSTALL_*DIR variables. Addresses concerns raised in #326, #346, #648 Closes #648
DRC 6c5caf30 2023-01-27T18:30:11 Merge branch 'main' into dev
DRC 3b19db4e 2023-01-27T18:24:41 BUILDING.md: Specify install prefix for MinGW/Un*x The default install prefix when building under MinGW is chosen based on the needs of the official build system, which uses MSYS2 to generate Windows installer packages that install under c:\libjpeg-turbo-gcc[64]. However, attempting to configure the build with that install prefix on a Un*x machine causes a CMake error. Fixes #641
DRC 0f047a57 2022-11-30T18:45:50 Merge branch 'main' into dev
DRC 7f2eb09d 2022-11-30T18:16:14 BUILDING.md: Add Arm64 iOS sim build instructions Unfortunately, iOS builds cannot be used with the iOS simulator on Macs with Apple silicon CPUs. Even more unfortunately, universal binaries can only have one slice for each CPU architecture, so it would not be possible to add a dedicated Arm64 iOS simulator slice to the existing libjpeg-turbo iOS binaries. (It would be necessary to release a separate package solely for the iOS simulator.) Because the Arm Neon SIMD extensions for libjpeg-turbo now use compiler intrinsics when building with Xcode, it is easy to build libjpeg-turbo from source when targeting Arm64-based Apple platforms. Thus, for the moment, I have chosen to document how to avoid the pothole rather than to fill it in.
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 2cad2169 2022-09-12T21:54:35 BUILDING.md: Acknowledge RHEL 9
DRC df3c3dcb 2022-03-31T10:22:06 BUILDING.md: Generify PowerTools repo advice This advice applies to CentOS Stream as well as to popular CentOS 8 replacements, such as Rocky Linux and AlmaLinux.
DRC 05655481 2022-02-28T20:41:56 BUILDING.md: Mention sub-project best practices People keep trying to include libjpeg-turbo into downstream CMake-based build systems by way of the add_subdirectory() function and requesting upstream support when something inevitably breaks. (Refer to: #122, #173, #176, #202, #241, #349, #353, #412, #504, https://github.com/libjpeg-turbo/libjpeg-turbo/commit/a3d4aadd0d1597ad46edcbe3b964499ec785d40c#commitcomment-67575889). libjpeg-turbo has never supported that method of sub-project integration, because doing so would require that we (minimally): 1. avoid using certain CMake variables, such as CMAKE_SOURCE_DIR, CMAKE_BINARY_DIR, and CMAKE_PROJECT_NAME; 2. avoid using implicit include directories and relative paths; 3. provide a way to optionally skip the installation of libjpeg-turbo components in response to 'make install'; 4. provide a way to optionally postfix target names, to avoid namespace conflicts; 5. restructure the top-level CMakeLists.txt so that it properly sets the PROJECT_VERSION variable; and 6. design automated CI tests to ensure that new commits don't break any of the above. Even if we did all of that, issues would still arise, because it is impossible for one upstream build system to anticipate the widely varying needs of every downstream build system. That's why the CMake ExternalProject_Add() function exists, and it is my sincere hope that adding a blurb to BUILDING.md mentioning the need to use that function will head off future GitHub issues on this topic. If not, then I can at least post a link to this commit and the blurb and avoid doing the same song and dance over and over again.
DRC ab6cae6f 2022-02-22T10:23:19 BUILDING.md: Clarify that Ninja works with Windows
DRC 3ccb6ead 2022-02-11T10:05:18 BUILDING.md: Remove NASM RPM rebuild instructions All currently supported Linux platforms now provide a recent enough version of either NASM or Yasm.
DRC 6441ad0f 2022-02-11T09:56:41 BUILDING.md: Document NASM/Yasm path variables This was an oversight from the CMake build system overhaul in libjpeg-turbo 2.0 (6abd39160c5a3762e9ebe024e75407665093e715). Closes #580
DRC 6d2d6d3b 2022-02-11T09:34:01 "YASM" = "Yasm" The assembler name was initially spelled "YASM", but it has been "Yasm" for the entirety of libjpeg-turbo's existence.
DRC 1388ad67 2020-12-08T21:25:47 Build: Officially support Ninja
DRC 0ba70b6a 2020-11-18T15:01:24 Build: Support macOS Armv8/x86-64 univ. binaries - Rename IOS_ARMV8_BUILD to ARMV8_BUILD. - Rename install_ios() to install_subbuild() in makemacpkg. - Wordsmith the build instructions accordingly. - Use xcode12.2 image in Travis CI.
DRC f7a10a61 2020-11-17T13:51:28 Build: "OS X"/"OSX" = "macOS"/"MACOS" There are no supported versions of "OS X" anymore. The operating system has been named "macOS" since 10.12 Sierra, which was released four years ago.
DRC 8f830598 2020-11-13T15:21:26 Merge branch 'master' into dev
DRC 42f7c78f 2020-11-13T15:18:35 BUILDING.md: Use min. iOS v8 in iOS Armv8 example This is necessary in order to enable thread-local storage.
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 bbd80892 2020-11-10T17:54:14 Neon: Finalize intrinsics implementation - Remove gas-preprocessor.pl. None of the compilers that can build the new intrinsics implementation require gas-preprocessor.pl (tested with Xcode and with Clang 3.9+ for Linux.) - Document that Xcode 6.3.x or later is now required for iOS builds (older versions of Xcode do not have a full set of Neon intrinsics.) - Add a change log entry. - Do not enable the ASM CMake language unless NEON_INTRINSICS is false. - Add a Clang/Arm64 test to .travis.yml in order to test the new intrinsics implementation. Closes #455
DRC 59352195 2020-10-19T21:17:46 Merge branch 'master' into dev
DRC 1ed312ea 2020-10-15T17:47:31 "ARM"="Arm", "NEON"="Neon" Refer to: https://www.arm.com/company/policies/trademarks/arm-trademark-list/arm-trademark https://www.arm.com/company/policies/trademarks/arm-trademark-list/neon-trademark NOTE: These changes are only applied to change log entries for 2.0.x and later, since the change log is a historical record and Arm's new trademark policy did not go into effect until late 2017.
DRC c77783ed 2020-06-25T21:28:33 BUILDING.md: Undocument 32-bit Mac build/packaging (oversight from previous commit)
DRC b797f700 2020-06-25T19:05:45 Build: Eliminate Cygwin packaging support We haven't provided official Cygwin builds since 1.4.x, since Cygwin now supplies its own libjpeg-turbo packages (although they apparently haven't been updated past 1.5.3.)
DRC 9a2cf323 2020-02-11T13:41:43 Build: Enable separate iOS pkg/DMG w/ sim support Refer to #406
DRC ada6ea51 2020-01-16T20:52:15 BUILDING.md: Update Visual C++ recommendations
DRC cbf0fcc8 2019-11-05T11:56:06 i386 SSE2 Huffman: Fix pointer arithmetic issue Splitting the pointer arithmetic in GET_SYM() into a separate add and sub instruction was an attempt to work around an error ("invalid operand type") that occurred when assembling the file with NASM. However, this created a link error on macOS ("ld: illegal text-relocation to '_jconst_huff_encode_one_block' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o from '_jsimd_huff_encode_one_block_sse2' in simd/CMakeFiles/simd.dir/i386/jchuff-sse2.asm.o for architecture i386") and also changed the alignment of the code in ways that might have affected the previous benchmark results (which took a great deal of time to obtain.) Ultimately, the path of least resistance is just to require NASM 2.13 or later.
DRC bbedb4b5 2019-11-05T15:43:21 Merge branch 'master' into dev
DRC cf54623b 2019-11-05T12:21:25 Mac: Support hiding SIMD fct symbols w/ NASM 2.14+ (NASM 2.14+ now supports the private_extern section directive, which was previously only available with YASM.)
DRC 2ae2bd66 2019-10-04T16:05:11 Remove support for Apple's Java implementation (AKA "Java for OS X systems.") This implementation of Java 1.6 is long obsolete and not supported on any version of macOS past High Sierra. Oracle no longer provides a 32-bit JVM on macOS, so it is no longer necessary to provide a 32-bit version of the TurboJPEG Java wrapper on macOS.
DRC b7523059 2019-10-04T15:53:30 Merge branch 'master' into dev
DRC ec4cacc1 2019-10-02T16:35:17 BUILDING.md: Document need for CRB/PowerTools repo NASM and YASM are located in this non-default repository on (respectively) RHEL and CentOS.
DRC c055c880 2019-05-09T20:36:51 Discontinue support for 32-bit iOS builds
DRC 5308c1a0 2019-01-22T12:11:03 BUILDING.md: Update/simplify Android build instr. Use the android.toolchain.cmake toolchain file in the NDK (v13b or later), since this toolchain file generally takes care of setting the approprate compiler flags and dealing with the differences between GCC and Clang. Our custom Android build procedure did not work with Clang-based NDK toolchains, which meant that it could not be made to work with NDK v18b or later. Fixes #309
DRC c1f07a9f 2018-09-21T15:12:38 BUILDING.md: Correct/update Java information - CMake 3.10.x or later must be used with JDK 11, or an error ("regex not supported") will occur when CMake tries to parse the Java version number. - The JDK is no longer available at java.com.
DRC 574f3a77 2018-07-27T11:44:46 Clarify Android Windows build instructions (must add .exe to CMAKE_C_COMPILER) Addresses a concern raised in #245, #260
DRC f4b8a5cf 2018-07-02T11:42:06 BUILDING.md: Correct iOS/Android examples toolchain.cmake should be created in the build directory, so the scripts need to cd to that directory before generating that file. Closes #254
DRC 367a8386 2018-02-26T19:41:59 Make SIMD syms private for x86[-64]/Mach-O builds ... if building with YASM. NASM doesn't currently support the necessary directives. Closes #212
Matthieu Darbois 32eaeeac 2018-02-24T18:00:51 Fix BUILDING.md buglet ("--mfloat-abi=softfp") (Introduced with the build system overhaul) Closes #215
DRC bd544e28 2017-12-16T09:34:28 Merge branch 'master' into dev
DRC 7d3feda7 2017-12-15T16:45:25 BUILDING.md: Adjust Android recipes for NDK r16+ NDK r16b moved some things around, so modify the Android build recipes to take that into account while preserving compatibility with previous NDK releases. NOTE: the GCC 4.9 NDK toolchain is deprecated, so we will need to develop new Android build recipes for libjpeg-turbo 1.6 that use the Clang toolchain. Closes #196
DRC b9ab64d8 2017-05-11T21:02:29 TurboJPEG: Thread-safe error message retrieval Introduce a new C API function (tjGetErrorStr2()) that can be used to retrieve compression/decompression/transform error messages in a thread-safe (i.e. instance-specific) manner. Retrieving error messages from global functions is still thread-unsafe. Addresses a concern expressed in #151.
DRC 2ac4e9d9 2017-06-26T21:58:32 Merge branch 'master' into dev
DRC 301ba4f3 2017-06-26T15:15:08 BUILDING.md: Include Android/x86 build recipes Addresses a concern raised in #155.
DRC 2fb4d7e3 2016-12-11T22:38:30 BUILDING.md: Documentation buglet `make cygwinpkg` was listed under "Mac".
DRC c8358fcb 2016-12-08T14:43:59 Build: Various improvements to install/pkg system - GNUInstallDirs: any directory variable can now reference any other directory variable by including its name in angle brackets (<>). - Changed the documentation of the directory variables in BUILDING.md accordingly. This commit also includes some formatting tweaks to that section (using boldface for directory names, as is our convention.) - Changed the package scripts such that they use CMAKE_INSTALL_DATAROOTDIR rather than CMAKE_INSTALL_DATADIR. - We no longer override the install dir. defaults on Windows unless performing an official build. It may be useful, for instance, to use the GNU defaults when installing into an MSYS environment.
DRC b0fcd0cc 2016-12-07T19:14:20 Build: Minor tweaks to GNUInstallDirs defaults It isn't actually necessary to specify `CMAKE_INSTALL_DEFAULT_MANDIR` for our official build. Because `CMAKE_INSTALL_DEFAULT_DATAROOTDIR` is blank for the official build, the default of "<DATAROOTDIR>/man" will resolve to "man". For the same reason, this commit changes the specification of `CMAKE_INSTALL_DEFAULT_DOCDIR` and `CMAKE_INSTALL_DEFAULT_JAVADIR` in the official build to be dependent on the data root directory (mainly to make it obvious what we're doing.) This commit also tweaks the example CMake command line in the directory variable documentation so that it shows the correct location of the CMake argument.
DRC d681fa76 2016-12-07T10:54:54 Build: Set install dirs in a more GNU-friendly way This builds upon the existing GNUInstallDirs module in CMake but adds the following features to that module: - The ability to override the defaults for each install directory through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`). Before operating system vendors began shipping libjpeg-turbo, it was meant to be a run-time drop-in replacement for the system's distribution of libjpeg, so it has traditionally installed itself under /opt/libjpeg-turbo on Un*x systems by default. On Windows, it has traditionally installed itself under %SystemDrive%\libjpeg-turbo*, which is not uncommon behavior for open source libraries (open source SDKs tend to install outside of the Program Files directory so as to avoid spaces in the directory name.) At least in the case of Un*x, the install directory behavior is based somewhat on the Solaris standard, which requires all non-O/S packages to install their files under /opt/{package_name}. I adopted that standard for VirtualGL and TurboVNC while working at Sun, because it allowed those packages to be located under the same directory on all platforms. I adopted it for libjpeg-turbo because it ensured that our files would never conflict with the system's version of libjpeg. Even though many Un*x distributions ship libjpeg-turbo these days, not all of them ship the TurboJPEG API library or the Java classes or even the latest version of the libjpeg API library, so there are still many cases in which it is desirable to install a separate version of libjpeg-turbo than the one installed by the system. Furthermore, installing the files under /opt mimics the directory structure of our official binary packages, and it makes it very easy to uninstall libjpeg-turbo. For these reasons, our build system needs to be able to use non-GNU-compliant defaults for each install directory if `CMAKE_INSTALL_PREFIX` is set to the default value. - For each directory variable, the module now detects changes to `CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly, if the variable has not been changed by the user. This makes it easy to switch between our "official" directory structure and the GNU-compliant directory structure "on the fly" simply by changing `CMAKE_INSTALL_PREFIX`. Also, this new mechanism eliminated the need for the crufty mechanism that previously did the same thing just for the library directory variable. How it should work: - If a dir variable is unset, then the module will set an internal property indicating that the dir variable was initialized to its default value. - If the dir variable ever diverges from its default value, then the internal property is cleared, and it cannot be set again without unsetting the dir variable. - If the install prefix changes, and if the internal property indicates that the dir variable is still set to its default value, and if the dir variable's value is not being manually changed at the same time that the install prefix is being changed, then the dir variable's value is automatically changed to the new default value for that variable (as determined by the new install prefix.) - The directory variables are now always cached, regardless of whether they were set on the command line or not. This ensures that they can easily be examined and modified after being set, regardless of how they were set. This was made possible by the introduction of the aforementioned `CMAKE_INSTALL_DEFAULT_*DIR` variables. - Improved directory variable documentation (based on descriptions at https://www.gnu.org/prep/standards/html_node/Directory-Variables.html) - The module now allows "<DATAROOTDIR>" to be used as a placeholder in relative directory variables. It is replaced "on the fly" with the actual path of `CMAKE_INSTALL_DATAROOTDIR`. This should more closely mimic the behavior of the old autotools build system while retaining our customizations to it, and it should retain the behavior of the old CMake build system. Closes #124
DRC 6abd3916 2016-11-15T08:47:43 Unified CMake-based build system See #56 for discussion. Fixes #21, Fixes #29, Fixes #37, Closes #56, Fixes #58, Closes #73 Obviates #82 See also: https://sourceforge.net/p/libjpeg-turbo/feature-requests/5/ https://sourceforge.net/p/libjpeg-turbo/patches/5/
DRC 9df7ac2e 2016-11-18T08:31:49 BUILDING.md: NASM 2.10+/YASM 1.2.0+ always needed ... for all x86[-64] builds, because we now have both 64-bit and 32-bit AVX2 SIMD extensions.
DRC 9fdb8f85 2016-11-22T09:33:19 Merge branch 'master' into dev
DRC f9f0c75b 2016-11-20T20:59:55 BUILDING.md: Clarifications and wordsmithing Updated out-of-date information, wordsmithed and clarified many sections, and generally cleaned up the build recipes (including a complete overhaul of the iOS recipes.)
DRC ab664e35 2016-11-18T09:09:41 BUILDING.md/README.md: Increment libjpeg SO age Documentation buglet. This should have been changed in 6ed4d9d11085acd04dc7f2f899848693976dc010 to reflect the addition of libjpeg API functions in libjpeg-turbo 1.5.
DRC a280fa63 2016-11-15T09:52:49 BUILDING.md: Don't use trailing spaces as line break Makes it easier to maintain this file using editors that automatically remove trailing spaces.
DRC 6c365686 2016-09-20T18:09:15 Merge branch 'master' into dev
DRC e9d9c31f 2016-09-19T22:47:18 Build: Remove ARMv6 support from 'make iosdmg' The last iDevice to require ARMv6 was the iPhone 3G, which required iOS 4.2.1 or older. Our binaries have always required iOS 4.3 or newer, so I'm not sure if the ARMv6 fork of our binaries was ever useful to begin with. In any case, if it ever was useful, it no longer is. Fat binaries can still be generated with ARMv6 support by invoking {build_directory}/pkgscripts/makemacpkg manually.
DRC 426d787c 2016-05-28T16:42:44 64-bit AVX2 impl. of RGB->YCC color conversion
DRC 1d50a8cd 2016-05-31T22:48:52 BUILDING.md: More NASM/YASM clarifications 28d1a1300c6be7fc8614ed827eb56cd97cf84e76 introduced the line "nasm.exe should be in your PATH". This commit corrects an oversight in 8f1c0a681cd34e8e80ba7b06f356d6080a7172c9 / e5091f2cf3b6ba747907012146df93df0d01ec85 whereby this line should have been extended to include yasm.exe.
DRC e5091f2c 2016-05-28T18:19:45 Merge branch '1.4.x'
DRC 0d61e80a 2016-05-01T12:07:05 Merge branch '1.4.x'
DRC 2628c562 2016-04-14T14:19:19 BUILDING.md: Fix "... OR ..." indentation again <sigh> GitHub doesn't render indented text the same as my local MarkDown viewer (MacDown), so it's necessary to indent "... OR ..." by 3 spaces so both will display it on the same indentation level as "Visual C++ 2005 or later" and "MinGW".
DRC 28d1a130 2016-04-14T14:12:46 BUILDING.md: Fix confusing Windows build reqs Indent "... OR ..." to make it clear that the choice is between Visual C++ and MinGW, not Visual C++ and MinGW + NASM. Move NASM to the top of the list to make that even more clear. Make it clear that nasm.exe should be in the PATH. Addresses concerns raised in #70
DRC 4f581231 2016-03-09T17:23:45 BUILDING.md and README.md: Cosmetic tweaks
DRC ab80273b 2016-02-08T14:41:07 BUILDING.md: Update OS X Java information The Apple Java Developer Package is only necessary on OS X < 10.7. When building on Lion and later, the Oracle JDK is preferred.
DRC 8ff67fdb 2016-02-06T12:17:40 Update MinGW Linux build recipe
DRC 6c3fc97b 2016-02-01T11:12:22 Update Android build instr. for ARMv8, PIE, etc. * Include information on how to do a 64-bit ARMv8 build with the latest NDK * Suggest -fPIE and -pie as default CFLAGS (required for android-16 and later. * Remove -fstrict-aliasing flag (-Wall already includes it)
DRC 4e356a92 2016-01-13T12:25:03 BUILDING.md: Restore autotools processing instr. Partially reverts 54014d9c2a41905b7b766057af6728834da64b59. When building from a git sandbox, as opposed to from an official source tarball, it is still necessary to run autoreconf. Closes #48
DRC f3a8684c 2016-01-07T00:19:43 SSE2 SIMD implementation of Huffman encoding Full-color compression speedups relative to libjpeg-turbo 1.4.2: 2.8 GHz Intel Xeon W3530, Linux, 64-bit: 2.2-18% (avg. 9.5%) 2.8 GHz Intel Xeon W3530, Linux, 32-bit: 10-25% (avg. 17%) 2.3 GHz AMD A10-4600M APU, Linux, 64-bit: 4.9-17% (avg. 11%) 2.3 GHz AMD A10-4600M APU, Linux, 32-bit: 8.8-19% (avg. 15%) 3.0 GHz Intel Core i7, OS X, 64-bit: 3.5-16% (avg. 10%) 3.0 GHz Intel Core i7, OS X, 32-bit: 4.8-14% (avg. 11%) 2.6 GHz AMD Athlon 64 X2 5050e: Performance-neutral (give or take a few percent) Full-color compression speedups relative to IPP: 2.8 GHz Intel Xeon W3530, Linux, 64-bit: 4.8-34% (avg. 19%) 2.8 GHz Intel Xeon W3530, Linux, 32-bit: -19%-7.0% (avg. -7.0%) Refer to #42 for discussion. Numerous other approaches were attempted, but this one proved to be the most performant across all platforms. This commit also fixes #3 (works around, really-- the clang-compiled version of jchuff.c still performs 20% worse than its GCC-compiled counterpart, but that code is now bypassed by the new SSE2 Huffman algorithm.) Based on: https://github.com/mayeut/libjpeg-turbo/commit/2cb4d41330e1edc4469f6b97ba73b73abfbeb02f https://github.com/mayeut/libjpeg-turbo/commit/36c94e050d117912adbff9fbcc6fe307df240168
DRC 17de5183 2015-10-10T10:34:55 Markdown versions of README, LICENSE, BUILDING
DRC 7e3acc0e 2015-10-10T10:25:46 Rename README, LICENSE, BUILDING text files The IJG README file has been renamed to README.ijg, in order to avoid confusion (many people were assuming that that was our project's README file and weren't reading README-turbo.txt) and to lay the groundwork for markdown versions of the libjpeg-turbo README and build instructions.
kmx.io     mail     discord kmxgit v0.4.0