- Remove the CMake < 3.9 hack for setting the GENERATOR_IS_MULTI_CONFIG
variable, since we no longer support CMake < 3.15.
- Link with the proper C run-time library when building a Debug
configuration using the Ninja Multi-Config generator on Windows.
- Use the $<CONFIG> generator expression instead of the deprecated
CMAKE_CFG_INTDIR variable. $<CONFIG> has existed since CMake 3.0.
CMAKE_CFG_INTDIR has been deprecated since 3.21 and is poorly
supported with the Ninja Multi-Config generator.
- Extend support for the Ninja Multi-Config generator to the Un*x
packaging system.
Fixes#926
... if libjpeg-turbo is built with either WITH_SYSTEM_SPNG or
WITH_SYSTEM_ZLIB. This causes 'pkg-config --static --libs libturbojpeg'
to include the libspng and/or zlib dependencies, as appropriate.
Practically speaking, linking against the static TurboJPEG API library
using pkg-config is fraught, because
'pkg-config --static --libs libturbojpeg' returns a series of -l flags.
It is necessary to pass -Bstatic to the linker ahead of those flags, but
there is no way to specify whether libspng and zlib should be linked
statically or dynamically. Trying to link statically with libspng using
-lspng won't work, because a static build of libspng renames the library
libspng_static.a. Furthermore, few platforms provide a static version
of zlib.
In other words, this commit fixes a very esoteric and not very
supportable use case.
Currently only vcpkg and Slackware seem to provide a libspng CMake
package config file, and the one in Slackware is slightly broken. (It
doesn't include CMakeFindDependencyMacro, so find_dependency() fails.)
Thus, I am only barely confident that this works.
CMakeLists.txt:
- If WITH_SYSTEM_SPNG, silently try to find libspng via a CMake package
config file and fall back to using pkg-config.
- If WITH_SYSTEM_SPNG, allow the imported libspng target to be
overridden with a new CMake variable (SPNG_TARGET.)
Config.cmake.in:
- If WITH_SYSTEM_SPNG, call find_dependency(SPNG) if the libspng
imported target doesn't start with PkgConfig::.
Further addresses limitations discussed in #901
If WITH_SYSTEM_ZLIB or WITH_SYSTEM_SPNG is defined, then the generated
CMake package config file will include (respectively)
INTERFACE_LINK_LIBRARIES "ZLIB::ZLIB"
or
INTERFACE_LINK_LIBRARIES "PkgConfig::spng"
in the libjpeg-turbo::turbojpeg and libjpeg-turbo::turbojpeg-static
target properties. Thus, our CMake package config file needs to find
those dependencies.
Fixes#901
This fully reverts c96e93b1f2.
Specifying a full path with install(TARGETS ...) causes the paths in the
CMake package config files to be hard-coded, which effectively makes the
package non-relocatable. Specifying a full path with other install()
commands breaks the --prefix option to cmake --install. There is in
fact no sane way to support blank install directories. Integrators who
wish to install certain files into the main libjpeg-turbo install
directory can set a particular CMAKE_INSTALL_*DIR variable to
"<CMAKE_INSTALL_PREFIX>", with the understanding that doing so will
break relocatability in the same way that
c96e93b1f2 did.
This commit also tweaks the RPM spec so that RPMs built from a source
RPM will contain relocatable CMake package config files.
- 32-bit x86 isn't common anymore.
- "MIPS" included Loongson, so removing mention of MIPS in
81538b1c22 technically made the list of
supported CPU architectures incomplete. However, both MIPS and
MIPS-based Loongson architectures are deprecated, even though
libjpeg-turbo continues to support the latter.
- Adding RISC-V to the list would have made it too long, especially if
I re-added MIPS.
- It was always awkward to mention specific CPU architectures, because
not all of the SIMD extension implementations are at least 2x faster
than libjpeg across the board. (Generally speaking, only the x86,
Arm, and PowerPC implementations are.)
- "All Rights Reserved" is no longer necessary, since all Buenos Aires
Convention signatories signed onto the Berne Convention in 2000.
- The phrase is confusing with respect to open source software, since
all rights are not in fact reserved. (The IJG README file even
clarifies: "All Rights Reserved except as specified below.")
- The phrase is even more confusing when a piece of source code has
multiple authors, because in that case, no one person owns the
copyright. (Thus, no one person can reserve all of the rights.)
- The zlib-licensed SIMD source code used the phrase inconsistently.
Historically, I introduced the phrase in conjunction with the
BSD-licensed TurboJPEG API source code in 1.2.x, probably because I
saw the phrase used in other BSD-licensed software. It then crept
into the Neon SIMD extensions in 1.2.x, the DSPr2 SIMD extensions in
1.4.x, the AltiVec SIMD extensions in 1.5.x, and the MMI SIMD
extensions in 2.0.x, due to similar oversights. However, because the
x86 SIMD extensions never used the phrase, the SIMD dispatchers (which
were based upon the x86 SIMD dispatcher) never used it either.
- Other libjpeg-turbo contributors who added "All Rights Reserved" to
their copyright notices did so only to conform to the existing
convention of the libjpeg-turbo code base, so this commit does not
violate their intent, nor does it change the legal meaning or strength
of their attributions.
- The Modified (3-clause) BSD License and zlib License never contained
the phrase "All Rights Reserved" (although earlier BSD licenses did),
so the addition of the phrase to our licenses could be incorrectly
interpreted as a license variation.
There are plenty of examples of open source software that uses "All
Rights Reserved" in conjunction with the BSD or zlib License. I was
probably following one of those examples when I used the phrase in my
own code. Using "All Rights Reserved" was encouraged for individual
copyright holders prior to the year 2000, so those of us who started
creating content in the 1990s or before still fall back upon that old
habit sometimes.
With respect to code I didn't author, the only thing that might be
construed to legally forbid this change is the first clause in the
Modified BSD License, which reads:
- Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.
and the last clause in the zlib License, which reads:
3. This notice may not be removed or altered from any source
distribution.
However, the spirit of these clauses is to prevent downstream users and
distributors from altering authorship attributions and thus implying
that they wrote the code. The clauses were not intended to prevent
upstream maintainers from removing a legally obsolete and confusing
phrase from contributed code that they committed, particularly when the
phrase (a) was never meant to be used with the license in the first
place, and (b) was, in most cases, added by the maintainer rather than
the contributor.
The contributions this applies to are from:
- https://sourceforge.net/p/libjpeg-turbo/patches/74
- #158
- #538
- #845
In these cases, the code was submitted without a copyright attribution,
and I added it or requested that it be added on behalf of the authors
(who expressed their intent for the attribution to conform to the code
base's existing copyright header format.)
- #628
In this case, the code was submitted without "All Rights Reserved"
attached, and I added the phrase for consistency.
- https://sourceforge.net/p/libjpeg-turbo/mailman/message/32981447
In this case, I obtained explicit permission from the author to remove
the phrase.
- #455
Permission has been requested, so this change has not yet been applied
to the Neon SIMD extensions.
- Put a space after (C) in BSD-licensed source files.
- Add missing trailing period in jcphuff-sse2.asm.
- Remove comma after copyright date in src/md5/md5.c.
Referring to #835, there were long-standing bugs in some of the modules,
which necessitated disabling those modules. Over the past four months,
I have tried and failed to find any parties interested in fixing those
bugs (including the parties who contributed the DSPr2 extensions.) I
interpret that as a strong sign that no one in the community cares about
the DSPr2 extensions anymore, but let's see if anyone complains before
3.2 beta1.
See ChangeLog.md for additional justifications, but suffice it to say
that:
- MIPS was a dead architecture in 2021.
- In 2026, it's shuffled off its mortal coil, run down the curtain, and
joined the bleedin' choir invisible.
As with x86-64, the Power ISA basically implements 64-bit instructions
as extensions of their 32-bit counterparts. Thus, 64-bit Power ISA CPUs
can natively execute legacy 32-bit PowerPC instructions when running in
big-endian mode. Most Power ISA support has shifted (pun intended) to
little-endian mode, so there are few remaining operating systems that
support big-endian mode. Debian is one of them, however (albeit
unofficially.)
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.
- Move all libjpeg documentation, except for README.ijg, into the doc/
subdirectory.
- Move the TurboJPEG C API documentation from doc/html/ into
doc/turbojpeg/.
- Move all C source code and headers into a src/ subdirectory.
- Move turbojpeg-jni.c into the java/ subdirectory.
Referring to #226, there is no ideal solution to this problem. A
semantically ideal solution would have involved placing all source code,
including the SIMD and Java source code, under src/ (or perhaps placing
C library source code under lib/ and C test program source code under
test/), all header files under include/, and all documentation under
doc/. However:
- To me it makes more sense to have separate top-level directories for
each language, since the SIMD extensions and the Java API are
technically optional features. src/ now contains only the code that
is relevant to the core C API libraries and associated programs.
- I didn't want to bury the java/ and simd/ directories or add a level
of depth to them, since both directories already contain source code
that is 3-4 levels deep.
- I would prefer not to separate the header files from the C source
code, because:
1. It would be disruptive. libjpeg and libjpeg-turbo have
historically placed C source code and headers in the same
directory, and people who are familiar with both projects (self
included) are used to looking for the headers in the same directory
as the C source code.
2. In terms of how the headers are used internally in libjpeg-turbo,
the distinction between public and private headers is a bit fuzzy.
- It didn't make sense to separate the test source code from the library
source code, since there is not a clear distinction in some cases.
(For instance, the IJG image I/O functions are used by cjpeg and djpeg
as well as by the TurboJPEG API.)
This solution is minimally disruptive, since it keeps all C source code
and headers together and keeps java/ and simd/ as top-level directories.
It is a bit awkward, because java/ and simd/ technically contain source
code, even though they are not under src/. However, other solutions
would have been more awkward for different reasons.
Closes#226
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
(7fec5074f9) 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.
e8b40f3c2b 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
6c2bc901e2, 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.
The Gordian knot that 7fec5074f9 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.
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.
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
This resolves a conflict between the RPM generated by the libjpeg-turbo
build system and the Red Hat 'filesystem' RPM if
CMAKE_INSTALL_LIBDIR=/usr/lib[64]. This code was largely borrowed from
the VirtualGL RPM spec. (I can legally do that because I hold the
copyright on VirtualGL's implementation.)
Fixes#532
- 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.
The previous AArch64 GAS implementation has been removed, since the
intrinsics implementation provides the same or better performance.
There was no previous AArch32 GAS implementation.
The checkstyle script was hastily developed prior to libjpeg-turbo 2.0
beta1, so it has a lot of exceptions and is thus prone to false
negatives. This commit eliminates some of those exceptions.
- 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.
IIRC, this was only necessary with the version of Java 1.5 that shipped
with OS X 10.4 "Tiger". Apple's implementation of Java 6 ("Java for
OS X Systems") supported both .jnilib and .dylib extensions for JNI
libraries, but Oracle's implementation of Java has only ever supported
the .dylib extension.
The scales have now tilted overwhelmingly in favor of eliminating
support for 32-bit Macs:
- 32-bit applications are only necessary in order to support OS X 10.5
"Leopard" and OS X 10.6 "Snow Leopard". OS X 10.7 "Lion" requires a
64-bit Mac and supports all 64-bit Macs.
- 32-bit applications are no longer allowed in the macOS App Store.
- 32-bit applications no longer run in macOS 10.15 "Catalina".
- 32-bit applications do not support thread-local storage, so the
TurboJPEG API library's global error handler is not thread-safe with
such applications.
- libjpeg-turbo 2.1.x no longer supports 32-bit iOS apps, so it makes
sense to also eliminate support for 32-bit macOS applications.
It's time.
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.)
