Eliminated the awkward and confusing "TurboJPEG/OSS" designation, since there are no active implementations of the TurboJPEG API anymore; don't refer to the libjpeg API library as "libjpeg-turbo" anymore, since that can be confusing;  ARM v7s build instructions
Actually, turbojpeg.c works with libjpeg as well
Wordsmith the project description
Oops.  Separate .def file is not needed when compiling with jpeg-8 API/ABI emulation.
Include ARM v7s (iPhone 5, iPad 4) support in the universal libjpeg/libturbojpeg libraries distributed with our official binary package for OS X.
Fix line break
Include a C version of md5cmp rather than depending on an external md5sum binary, since md5sum is not available on all platforms (specifically, it doesn't exist on FreeBSD, and it has to be installed via MacPorts on OS X.)
Fix 'make dist'
Trying to build ARM v7/v7s iOS binaries from the "official" libjpeg-turbo tarball (generated on RHEL4/autoconf 2.59/automake 1.9.2/libtool 1.5.6) using either Xcode 3.2.x or 4.5.x produces an error: "libtool: compile: unable to infer tagged configuration".  Further study is warranted, but the most expedient way around it at the moment is to re-run autoconf on the OS X machine that is being used to generate the iOS binaries.
Bump version for post-beta pre-releases
Add note about how to obtain PackageMaker if using recent Xcode releases.
It's more correct to say "The Independent JPEG Group's software", since libjpeg-turbo emulates both the command-line and application programming interfaces.
Document issues encountered when building on OS X 10.7 and later.
Grammar police
Remove unneeded headers (cdef.h isn't available on all platforms) and change u_int32_t to unsigned int, since u_int32_t isn't available on all platforms.  This fixes build issues on Solaris.
Formatting tweaks
Overhaul Linux/Unix packaging system, primarily to avoid conflicts with vendor-supplied libjpeg-turbo packages (such as in Fedora and RHEL 6.)  This also streamlines the packaging system somewhat, since it is no longer necessary to move the TurboJPEG libraries into the system library directory.  Relocating those libraries was originally done to provide backward compatibility with TurboJPEG/IPP, but that package is long obsolete, and the software that formerly used it has been linking statically with libjpeg-turbo for quite some time.

If the default prefix (/opt/libjpeg-turbo) is used, then we now always install 32-bit libraries in /opt/libjpeg-turbo/lib32 and 64-bit libraries in /opt/libjpeg-turbo/lib64 instead of trying to conform to the Debian or Red Hat conventions.  The RPM and DEB packages will now be created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc., with the exception that the docs are always installed under /usr/share/doc/{package_name}-{version}.
Further enhancements/fixes to the packaging system:
-- The Mac and Cygwin packages will now be created with the directory structure defined by the configure variables "prefix", "bindir", "libdir", etc., with the exception that the docs are always installed under /usr/share/doc/{package_name}-{version} on Cygwin and /Library/Documentation/{package_name} on Mac.
-- Fixed a duplicate filename warning when generating RPMs with the default prefix of /opt/libjpeg-turbo.
-- Moved the TurboJPEG libraries out of the system directory on Windows and Mac.  It is no longer necessary to put them there, since we are not trying to be backward compatible with TurboJPEG/IPP anymore.
-- Fixed an issue whereby building the "installer" target on Windows would not build the Java JAR file, thus causing an error if the JAR had not been previously built.
-- Building the "install" target on Windows will now install libjpeg-turbo into c:\libjpeg-turbo[-gcc][64] (the same directories used by the installers.)  This can be overridden by setting CMAKE_INSTALL_PREFIX.
-- The Java classes on all platforms will now look for the JNI library in the directory under which the build/packaging system installs it.
Fix 'make dist'