kc3-lang/libjpeg-turbo

Log

Author Commit Date CI Message
DRC c05d1249 2017-11-29T14:36:39 Merge branch 'master' into dev
DRC a831b5a9 2017-11-29T14:23:31 Travis: Work around xcode7.3 image bug Refer to travis-ci/travis-ci#8552. This was supposed to be fixed on November 15, then on November 28. Travis blew through both deadlines, so I have no confidence that the issue will be fixed as promised in a timely manner. Adding 'brew update' to .travis.yml slows the OS X build, but there is no choice at the moment.
DRC 9f1f86bf 2017-11-19T09:18:36 tjLoadImage(): Fix OOB array access w/TJPF_UNKNOWN Because the previous commit added a test for TJPF_UNKNOWN to tjunittest, the ASAN CI build detected this issue.
DRC e817c077 2017-11-19T08:43:07 tjLoadImage(): return TJPF_GRAY for grayscale BMPs ... if *pixelFormat=TJPF_UNKNOWN is passed to the function.
DRC 479fa1d8 2017-11-18T11:33:05 tjLoadImage(): Don't convert RGB to grayscale Loading RGB image files into a grayscale buffer isn't a particularly useful feature, given that libjpeg-turbo can perform this conversion much more optimally (with SIMD acceleration on some platforms) during the compression process. Also, the RGB2GRAY() macro was not producing deterministic cross-platform results because of variations in the round-off behavior of various floating point implementations, so `tjunittest -bmp` was failing in i386 builds.
DRC 8c40ac8a 2017-11-16T18:46:01 Add TurboJPEG C example and clean up Java example Also rename example.c --> example.txt and add a disclaimer to that file so people will stop trying to compile it.
DRC dc4b9002 2017-11-16T20:43:12 TurboJPEG: Add alpha offset array/method Also, set the red/green/blue offsets for TJPF_GRAY to -1 rather than 0. It was undefined behavior for an application to use those arrays/methods with TJPF_GRAY anyhow, and this makes it easier for applications to programmatically detect whether a given pixel format has red, green, and blue components.
DRC aa745905 2017-11-16T18:09:07 TurboJPEG C API: Add BMP/PPM load/save functions The main justification for this is to provide new libjpeg-turbo users with a quick & easy way of developing a complete JPEG compression/decompression program without requiring them to build libjpeg-turbo from source (which was necessary in order to use the project-private bmp API) or to use external libraries. These new functions build upon significant enhancements to rdbmp.c, wrbmp.c, rdppm.c, and wrppm.c which allow those engines to convert directly between the native pixel format of the file and a pixel format ("colorspace" in libjpeg parlance) specified by the calling program. rdbmp.c and wrbmp.c have also been modified such that the calling program can choose to read or write image rows in the native (bottom-up) order of the file format, thus eliminating the need to use an inversion array. tjLoadImage() and tjSaveImage() leverage these new underlying features in order to significantly improve upon the performance of the old bmp API. Because these new functions cannot work without the libjpeg-turbo colorspace extensions, the libjpeg-compatible code in turbojpeg.c has been removed. That code was only there to serve as an example of how to use the TurboJPEG API on top of libjpeg, but more specific, buildable examples now exist in the https://github.com/libjpeg-turbo/ijg repository.
DRC 087ec126 2017-11-15T20:50:53 tjbenchtest: Test new TurboJPEG progressive flag
DRC cd8a1258 2017-11-15T09:19:27 Build: Fix 'tjtest' target on Windows tjbenchtest and its Java derivatives are useful for rooting out hidden problems with the more esoteric TJBench and TurboJPEG features. For instance, on Windows, running tjbenchtest uncovered 5fce2e942136cb70e5a30ff15a2d58b07947aa84. This commit also causes tjbenchtest and tjbenchtest.java to append -yuv and -alloc to their log file names, depending on the arguments passed, and it causes the build system to clean up those log files when the 'testclean' target is built.
DRC 4893e5d8 2017-11-17T19:00:53 Merge branch 'master' into dev
DRC 19b393b6 2017-11-17T18:45:08 TJExample: Fix array index OOB w/ 4:1:1 JPEG input
DRC 9d9d8fe6 2017-11-17T18:15:42 Code formatting tweaks
DRC 78e97e38 2017-11-15T19:39:45 Uniquify tjbenchtest log file names based on args + clean up log files when 'make testclean' is invoked + fix 'tjbenchtest -yuv -alloc' + fix tjexampletest so that it creates images under /tmp + clean up tjexampletest
DRC 468f2fed 2017-11-15T19:33:06 TJExample.java: Don't ignore mistyped args
DRC 5abf2536 2017-11-14T16:12:13 Doc tweak: TJFLAG_ACCURATEDCT is the first flag
DRC 5fce2e94 2017-11-14T15:30:06 tjbench.exe: Fix decompression access violation The program crashed when a JPEG image was passed on the command line, because we were mixing our metaphors vis-a-vis malloc()/free() and tjAlloc()/tjFree() (malloc()/free() uses the tjbench.exe heap, whereas tjAlloc()/tjFree() uses the turbojpeg.dll heap.)
DRC 907dd683 2017-11-13T21:46:07 ChangeLog.md: buglet
DRC f008876c 2017-11-13T21:24:05 Build: Fix `make dist` Broken by previous commit
DRC 5bc43c78 2017-11-13T21:01:53 Further partial image decompression fixes - Referring to 073b0e88a192adebbb479ee2456beb089d8b5de7 and #185, the reason why BMP and RLE didn't (and won't) work with partial image decompression is that the output engines for both formats maintain a whole-image buffer, which is used to reverse the order of scanlines. However, it was straightforward to add -crop support for GIF and Targa, which is useful for testing partial image decompression along with color quantization. - Such testing reproduced a bug reported by Mozilla (refer to PR #182) whereby jpeg_skip_scanlines() would segfault if color quantization was enabled. To fix this issue, read_and_discard_scanlines() now sets up a dummy quantize function in the same manner that it sets up a dummy color conversion function. Closes #182
DRC f3ad13e3 2017-11-13T16:00:35 TJBench/TJUnitTest: Don't ignore mistyped args
DRC 94e152b1 2017-11-13T08:15:50 TurboJPEG C: Code formatting tweaks
DRC 073b0e88 2017-11-08T21:01:57 djpeg -crop: Exit gracefully with non-PPM formats ... and document that only PPM/PGM output images are supported with the -crop option for the moment. I investigated the possibility of supporting -crop with -bmp, but even after resetting the buffer dimensions, I still kept getting virtual array access errors. It seems that doing this the "right way" would require creating a re-initialization function for each image format's destination manager. I'm disinclined to do that right now, given that this feature was Google's baby (developed as a prerequisite for including libjpeg-turbo in Android), and the -crop option in djpeg is intended only as an example of how to use the partial image decompression API. Real-world applications would need to handle this in their own destination managers. It would probably be possible to make this work with Targa by employing a similar hack to the one we used with PPM, but Targa isn't popular enough to bother. Fixes #185
DRC 616b4e2d 2017-09-20T19:55:54 TurboJPEG C: Compiler warnings Introduced in b9ab64d8dbee2db829e59357d335c151680f44f0.
DRC 3d72522a 2017-09-20T18:11:03 SRPM build: Define _libdir based on build arch Setting _libdir to CMAKE_INSTALL_FULL_LIBDIR only works when doing an in-tree RPM build. SRPMs are architecture-agnostic, so the spec needs to compute_libdir at the time the SRPM is rebuilt, not at the time it is generated. This is a regression introduced when implementing the new CMake-based cross-platform build system.
DRC f0dd80f2 2017-09-20T17:13:46 Merge branch 'master' into dev
DRC 1b385f37 2017-09-20T16:52:48 Prevent "unmappable character" error in Java build This was causing the build to fail when rebuilding libjpeg-turbo from a source RPM.
DRC fd778bba 2017-09-19T20:01:34 Fix PowerPC 32-bit RPM build
DRC 8d403aeb 2017-09-19T13:03:49 Fix 32-bit RPM build w/ newer RHEL/Fedora releases The version of RPM on RHEL 5 and older platforms defines _libdir as %{_exec_prefix}/%{_lib}, so defining _lib in the spec file redefined _libdir. However, newer versions of RPM (probably >= 4.6, since that was the version that introduced the ISA macros) define _libdir as either %{_prefix}/lib or %{_prefix}/lib64. Thus, we need to explicitly override _libdir in our spec file.
DRC 01b74c10 2017-09-11T10:06:22 Packaging: Use parallel make when rebuilding SRPM
DRC db0dec3c 2017-09-11T09:48:33 Travis: Limit parallel make jobs to # of CPU cores This tends to be faster than 'make -j', since it is making more wise use of the available resources.
nyg ba6e9d8a 2017-09-05T18:23:04 wrjpgcom: Fix comment typo Comment was copied/pasted from skip_variable() without making the necessary modifications.
DRC 7106ffe5 2017-09-02T04:20:03 Merge branch 'master' into dev
DRC 5426a4cb 2017-09-02T04:08:06 TJUnitTest: Usage formatting tweaks
DRC d0bac69a 2017-09-02T03:40:46 Java: Fix TJUnitTest on big endian platforms It is necessary for the C code to be aware of the machine's endianness, which is why the TurboJPEG Java wrapper sets a different pixel format for integer BufferedImages depending on ByteOrder.nativeOrder(). However, it isn't necessary to handle endianness in pure Java code such as TJUnitTest (d'oh!) This was a product of porting the C version of TJUnitTest too literally, and of insufficient testing (historically, the big endian systems I had available for testing didn't have Java.)
DRC 59322e09 2017-09-01T21:57:48 Build: Change ppc64le DEB arch to ppc64el This is the convention among Debian-based distros.
DRC 51cc89fa 2017-09-01T09:02:55 Merge branch 'master' into dev
DRC 4ded4dfa 2017-09-01T09:01:00 Build: Fix AltiVec detection on OS X Leopard The ability to directly access elements of an AltiVec vector is apparently a more recent thing.
DRC 1d935416 2017-09-01T13:52:21 Build: Use -maltivec when testing AltiVec support Doesn't seem to be necessary with recent Linux/GCC configurations, but it is definitely necessary with OS X.
DRC c0f3512d 2017-08-31T20:57:19 Merge branch 'master' into dev
DRC 02fa8f24 2017-09-01T01:10:08 Fix build on PowerPC SPE systems SPE systems don't support AltiVec instructions. Fixes #172
DRC 32120054 2017-08-14T10:54:27 Java: Fix NullPointerException in YUVImage planes == null is a valid argument to setBuf() if alloc == true, so we need to make sure that planes is non-null before validating its length. We also need to allocate one dimension of the planes array if it's null. Fixes #168
DRC 14783612 2017-08-14T11:18:35 Bump version to 1.5.3 to prepare for new commits
DRC e5c1613c 2017-07-07T15:15:19 x86: Fix "short jump is out of range" w/ NASM<2.04
DRC c9453121 2017-06-29T16:49:09 TJBench: Recover from non-fatal errors if possible Previously, -stoponwarning only had an effect on the underlying TurboJPEG C functions, but TJBench still aborted if a non-fatal error occurred. This commit modifies the C version of TJBench such that it always recovers from a non-fatal error unless -stoponwarning is specified. Furthermore, the benchmark stores the details of the last non-fatal error and does not print any subsequent non-fatal error messages unless they differ from the last one. Due to limitations in the Java API (specifically, the fact that it cannot communicate errors, fatal or otherwise, to the calling program without throwing a TJException), it was only possible to make decompression operations fully recoverable within TJBench. With other operations, -stoponwarning still has an effect on the underlying C library but has no effect at the Java level. The Java API documentation has been amended to reflect that only certain methods are truly recoverable, regardless of the state of TJ.FLAG_STOPONWARNING.
DRC 9baef107 2017-06-29T12:08:02 TurboJPEG: Don't make STOPONWARNING persistent Due to an oversight in d4092f6b4dd94c64864662987b070d517c399490, the state of TJFLAG_STOPONWARNING persisted beyond the function it was passed to.
DRC dadebcd7 2017-06-28T11:43:08 TurboJPEG: Add "copy none", progressive xform opts Allow progressive entropy coding to be enabled on a transform-by-transform basis, and implement a new transform option for disabling the copying of markers. Closes #153
DRC dedce66e 2017-06-28T15:30:41 Merge branch 'master' into dev
DRC b0971e47 2017-06-28T14:47:45 TurboJPEG: Document xform issue w/ big marker data If the source image for a transform operation has a lot of EXIF or ICC data embedded in it, then it may cause the output image size to exceed the worst-case size returned by tjBufSize() (because tjTransform() transfers all markers to the output image.) This is only a problem if TJFLAG_NOREALLOC is passed to the function. Since the TurboJPEG C API doesn't require the destination image size to be set in this case, it makes the documented assumption that the calling program has allocated the destination buffer to exactly the size returned by tjBufSize(). Changing this assumption would change the API behavior and necessitate a new function name (tjTransform2().) At the moment, it's easier to just document this as a known issue, since it's easy to work around in the C API. The Java API is unfortunately a different story, since it must always use TJFLAG_NOREALLOC (because, when using the TurboJPEG Java API, all buffers are allocated on the Java heap, and thus they can't be reallocated by the C code.) There is no easy way to work around this without changing the C API as discussed above, because if the source image contains large amounts of marker data, it's virtually impossible to determine how big the output image will be.
DRC e248d430 2017-06-28T14:40:35 Java TJBench: Fix parsing of -warmup argument Due to an oversight, this wasn't included in 1db1ce45da2e78d87ff05119b674c71d630926aa.
DRC acb63493 2017-06-27T19:45:35 Build: Disable warmup in TJBench regression tests Fixes slow-down in 'make test' caused by previous commit.
DRC 1db1ce45 2017-06-27T14:22:39 TJBench: Improve consistency of results Given that libjpeg-turbo can often process hundreds of megapixels/second on modern hardware, the default of one warmup iteration was essentially meaningless. Furthermore, the -warmup option was a bit clunky, since it required some foreknowledge of how fast the benchmarks were going to execute. This commit introduces a 1-second warmup interval for each benchmark by default, and the -warmup option has been retasked to control the length of that interval.
DRC aba6ae59 2017-06-27T13:24:08 TurboJPEG: Opt. enable progressive entropy coding Fulfills part of the feature request in #153. Also paves the way for SIMD-accelerated progressive Huffman coding (refer to #46.)
DRC 596e3965 2017-06-27T11:51:34 Merge branch 'master' into dev
DRC d0c3aa90 2017-06-27T11:36:25 TurboJPEG: C API documentation buglet TJFLAG_NOREALLOC, tjAlloc(), and tjFree() apply to all TurboJPEG compression functions, not just tjCompress2().
DRC d4092f6b 2017-06-27T10:54:21 TurboJPEG: Improve error handling - Provide a new C API function and TJException method that allows calling programs to query the severity of a compression/decompression/ transform error. - Provide a new flag that instructs the library to immediately stop compressing/decompressing/transforming if a warning is encountered. Fixes #151
DRC 42e1e2d8 2017-06-26T19:19:44 Build: Custom target for generating JNI headers
DRC 25c912c1 2017-05-11T21:29:07 Build: Add custom target for generating Java docs
DRC 178796e7 2017-05-11T21:23:45 Build: Fix buglet in java/CMakeLists.txt (MSYS) CMAKE_HOST_SYSTEM_NAME should be restored with the value of CMAKE_HOST_SYSTEM_NAME_BAK.
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 6a2b0674 2017-05-11T18:33:47 TJBench: Code formatting tweaks Spaces-->tab + remove stray control character that was introduced in 95e4cb206085c3a715f0f017c174fdf367a2c1ff
DRC 11eec4a3 2017-06-26T20:48:02 TJBench: Fix errors when decomp. files w/ ICC data Embedded ICC profiles can cause the size of a JPEG file to exceed the size returned by tjBufSize() (which is really meant to be used for compression anyhow, not for decompression), and this was causing a segfault (C) or an ArrayIndexOutOfBoundsException (Java) when decompressing such files with TJBench. This commit modifies the benchmark such that, when tiled decompression is disabled, it re-uses the source buffer as the primary JPEG buffer.
DRC 301ba4f3 2017-06-26T15:15:08 BUILDING.md: Include Android/x86 build recipes Addresses a concern raised in #155.
DRC 70f236dd 2017-05-08T08:15:11 Travis: Fix OS X build The Travis xcode7.3 image now apparently includes GnuPG 1.4.x by default, so use it instead of installing GnuPG 2. Using GnuPG 2.1.x, the default version in Homebrew as of this writing, is problematic for this reason: https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase
DRC 2a4f1894 2017-05-05T20:45:40 Restore compatibility with older autoconf releases (broken by f06cc1200fd5f61b63479d7099ccf4a7457a89bd) Fixes #149
DRC 9d64f3c6 2017-04-24T14:42:58 Attribute ARM runtime detection code to Nokia This code was submitted in the initial ARM NEON patches (https://sourceforge.net/p/libjpeg-turbo/patches/7/) by Siarhei while he was still a Nokia employee.
DRC da2a27ef 2017-03-18T16:15:14 Honor max_memory_to_use/JPEGMEM/-maxmemory This re-introduces a feature of the obsolete system-specific libjpeg memory managers-- namely the ability to limit the amount of main memory used by the library during decompression or multi-pass compression. This is mainly beneficial for two reasons: - Works around a 2 GB limit in libFuzzer - Allows security-sensitive applications to set a memory limit for the JPEG decoder so as to work around the progressive JPEG exploit (LJT-01-004) described here: http://www.libjpeg-turbo.org/pmwiki/uploads/About/TwoIssueswiththeJPEGStandard.pdf This commit also removes obsolete documentation regarding the MS-DOS memory manager (which itself was removed long ago) and changes the documentation of the -maxmemory switch and JPEGMEM environment variable to reflect the fact that backing stores are never used in libjpeg-turbo. Inspired by: https://github.com/caolanm/libjpeg-turbo/commit/066fee2e7d6834f24838bc1896aa38ca77209e3c Closes #143
DRC c082dc03 2017-03-18T13:24:50 AppVeyor: Fix CI build Something changed in the CI build environment, and our previous trick of setting the Git URL to file://c:/projects/libjpeg-turbo no longer works. Using cygpath to translate the Windows path to a MinGW-friendly format is a better solution anyhow.
DRC d4c41fe0 2017-03-18T12:56:36 TurboJPEG: Fix potential memory leaks Referring to https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=746, it seems that the values of local buffer pointers in TurboJPEG API functions aren't always preserved if longjmp() returns control to a point prior to the allocation of the local buffers. This is known to be an issue with GCC 4.x and clang with -O1 and higher optimization levels but not with GCC 5.x and later. It is unknown why GCC 5.x and 6.x do not suffer from the issue, but possibly the local buffer pointers are not allocated on the stack when using those more recent compilers. In any case, this commit modifies the TurboJPEG API library code such that the jump buffer is always updated after any local buffer pointers are allocated but before any subsequent libjpeg API functions are called.
DRC 44b2399a 2017-01-19T15:18:57 libjpeg API: Support reading/writing ICC profiles This commit does the following: -- Merges the two glueware functions (read_icc_profile() and write_icc_profile()) from iccjpeg.c, which is contained in downstream projects such as LCMS, Ghostscript, Mozilla, etc. These functions were originally intended for inclusion in libjpeg, but Tom Lane left the IJG before that could be accomplished. Since then, programs and libraries that needed to embed/extract ICC profiles in JPEG files had to include their own local copy of iccjpeg.c, which is suboptimal. -- The new functions were prefixed with jpeg_ and split into separate files for the compressor and decompressor, per the existing libjpeg coding standards. -- jpeg_write_icc_profile() was made slightly more fault-tolerant. It will now trigger a libjpeg error if it is called before jpeg_start_compress() or if it is passed NULL arguments. -- jpeg_read_icc_profile() was made slightly more fault-tolerant. It will now trigger a libjpeg error if it is called before jpeg_read_header() or if it is passed NULL arguments. It will also now trigger libjpeg warnings if the ICC profile data is corrupt. -- The code comments have been wordsmithed. -- Note that the one-line setup_read_icc_profile() function was not included. Instead, libjpeg.txt now documents the need to call jpeg_save_markers(cinfo, JPEG_APP0 + 2, 0xFFFF) prior to calling jpeg_read_header(), if jpeg_read_icc_profile() is to be used. -- Adds documentation for the new functions to libjpeg.txt. -- Adds an -icc switch to cjpeg and jpegtran that allows those programs to embed an ICC profile in the JPEG files they generate. -- Adds an -icc switch to djpeg that allows that program to extract an ICC profile from a JPEG file while decompressing. -- Adds appropriate unit tests for all of the above. -- Bumps the SO_AGE of the libjpeg API library to indicate the presence of new API functions. Note that the licensing information was obtained from: https://github.com/mm2/Little-CMS/issues/37#issuecomment-66450180
DRC d9cb76f6 2017-01-16T15:55:02 Remove vestigial license text regarding autoconf
DRC d34d2559 2017-01-19T19:05:21 Merge branch 'master' into dev
DRC a0b7de9a 2017-01-19T18:51:41 Always tweak EXIF w/h tags w/ lossless transforms ... even if using libjpeg v6b emulation. Previously adjust_exif_parameters() was only called with libjpeg v7/v8 emulation, but due to a bug (which this commit also fixes), it only worked properly with libjpeg v8 emulation.
DRC 22527955 2017-01-19T17:50:59 Fix error w/ lossless crop & libjpeg v7 emulation The JPEG_LIB_VERSION #ifdef in jtransform_adjust_parameters() was incorrect, which caused a "Bogus virtual array access" error when attempting to use the lossless crop feature. Introduced in c04bd3cc97f44fd9030de1e141754c8775d4e5a5. This also adds libjpeg v7 API/ABI emulation to the Travis CI tests.
DRC eb38b61b 2017-01-19T16:44:10 Include jpeg_skip/crop_scanlines() in jpeg7.dll ... when the in-memory source/destination managers are included. Oversight in 306e1d2d778cf5a4d2a22ac847a31722b9fc2845 and 3ab68cf563f6edc2608c085f5c8b2d5d5c61157e.
DRC 47b29e8c 2017-01-19T15:36:58 libjpeg.txt: Include partial decomp. in TOC (oversight)
DRC e1e816e6 2017-01-19T15:33:48 Slightly de-confusify cjpeg, jpegtran usage info + bump copyright year
DRC 2fb4d7e3 2016-12-11T22:38:30 BUILDING.md: Documentation buglet `make cygwinpkg` was listed under "Mac".
DRC 8a9b042b 2016-12-10T09:35:30 Merge branch 'master' into dev
DRC 64410181 2016-12-10T09:32:23 LICENSE.md: Include text of BSD/zlib licenses LICENSE.md is included in the binary distributions as well, so it doesn't make much sense to refer to license headers in source files that aren't necessarily going to be there.
DRC 11426a87 2016-12-10T09:10:57 Packaging system: "PACKAGE_NAME" = "PKGNAME" Using PACKAGE_NAME as a variable name made more sense with autotools, but now it's more of an inconvenience variable than a convenience variable.
DRC 67ad5350 2016-12-10T09:00:39 Build: Don't require sudo for `make tarball` The whole point of `make tarball` is to make it easy for users to create a binary distribution of libjpeg-turbo on platforms that aren't supported by our official build system, so requiring root permissions somewhat defeated that purpose. Intead, the script now attempts to detect whether the system has GNU tar or a recent version of BSD tar that supports setting the ownership of the files in the tarball.
DRC 6c6696e5 2016-12-09T17:12:12 Mac pkg: Use PKGNAME for documentation directory Although there is little chance that we will ever have a package conflict on OS X, the convention from our Linux packages is to use the package name, not the project name, for the name of the documentation directory.
DRC 6530203f 2016-12-09T10:21:29 Build: More GNUInstallDirs improvements These improvements enable build systems to use GNUInstallDirs to define custom directory variables. - The set_dir() macro was renamed to GNUInstallDirs_set_install_dir(), in keeping with the module's established macro naming convention. - Rather than detecting whether the prefix has changed, the new GNUInstallDirs_set_install_dir() macro instead examines whether the default for the variable in question has changed. This allows for more flexibility, since build systems may decide to change the defaults based on factors other than the prefix. It also enables the macro to work properly outside of the module. - The module now performs directory variable substitution within the body of GNUInstallDirs_get_absolute_install_dir(). - The JAVADIR variable is no longer included in GNUInstallDirs. That directory is not part of the GNU spec, and it turns out that various operating systems use different conventions for the location of Java classes. Instead, the variable is now implemented in our build system as a demonstration of the aforementioned GNUInstallDirs enhancements.
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 2b29bca2 2016-12-07T18:11:38 Build: Fix Debug/RelWithDebInfo build with YASM YASM requires a debug format to be specified with -g. Currently the only combination that I can make work at all is DWARF-2/ELF (YASM doesn't support Mach-O debugging at all, and its support for CV8/MSVC and MinGW/DWARF-2 appears to be broken), so debugging is only enabled automatically for ELF at the moment. For other formats, we don't specify -g at all, which is how the old build system behaved. Fixes #125, Closes #126
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 ff05b6e0 2016-12-07T14:09:41 Build: Fix Win "installer" target Java dependency The correct target name is now "turbojpeg-java".
DRC e6426d24 2016-12-07T10:40:28 Build: Formatting tweak (It is our convention to use lowercase for CMake macro/function names)
DRC 2af2fe42 2016-12-05T16:52:54 Build: Clean up inline keyword detection Strict C89-conformant compilers don't support the "inline" keyword, but most of them support "__inline__", and that keyword can be used with the always_inline atribute as well. This commit also removes duplicate code by using a foreach() loop to test the various keywords.
DRC fcfc6c5e 2016-12-05T14:02:59 Fix build when CFLAGS contains -std=c89 (or -ansi) This is a subtle point, but AC_C_INLINE defines "inline" to be either "inline", "__inline__", or "__inline". The subsequent test for "inline __attribute__((always_inline))" uses this definition. The attribute is irrespective of the inline keyword, so whereas "__inline__ __attribute__((always_inline))" works under C89, "inline __attribute__((always_inline))" doesn't, and defining INLINE to the latter causes the build to fail. The easiest way around this is simply to define "inline" ahead of "INLINE" in jconfigint.h, which causes the inline keyword detected by AC_C_INLINE to modify the INLINE macro if necessary.
DRC 786b6493 2016-12-05T12:39:49 Reorg AltiVec detection code + advertise that full AltiVec SIMD acceleration is now available on OpenBSD. The relevant compilers probably all support C99 or GNU's variation of C90 that allows variables to be declared anywhere, but our policy is to conform to the C90 standard, if for no other reason than that it improves code readability.
Donovan Watteau f4ba09b3 2016-12-03T15:46:49 Detect AltiVec support on OpenBSD
DRC 261db770 2016-12-03T15:51:58 Packaging: Use correct name for SRPM spec file Per convention, the file should be named {package name}.spec.
Colin Cross 0f4fcced 2016-12-01T16:56:18 Fix sign mismatch comparison warnings Fixes: rdppm.c:257:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:284:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:289:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval) ~~~~ ^ ~~~~~~ rdppm.c:294:14: warning: comparison of integers of different signs: 'int' and 'unsigned int' [-Wsign-compare] if (temp > maxval)
DRC 952191da 2016-12-03T14:21:11 Build: Fix issues when building as a Git submodule - Replace CMAKE_SOURCE_DIR with CMAKE_CURRENT_SOURCE_DIR - Replace CMAKE_BINARY_DIR with CMAKE_CURRENT_BINARY_DIR - Don't use "libjpeg-turbo" in any of the package system filenames (because CMAKE_PROJECT_NAME will not be the same if building LJT as a submodule.) Closes #122
DRC d642da75 2016-12-03T13:38:21 Build: Fix buglet in output of `make tjtest`
DRC 059c9a5f 2016-12-03T21:17:09 Build: Fix regression in AltiVec SIMD detection Only the SIMD source files should be built with -maltivec. Otherwise the detection code will not be compiled in.
kmx.io     mail     discord kmxgit v0.4.0