Implement in-memory source/destination managers even when not emulating the libjpeg v8 API/ABI


git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@913 632fc199-4ca6-4c93-a231-07263d6284db
Compiler warnings on Windows


git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@914 632fc199-4ca6-4c93-a231-07263d6284db
Since Windows doesn't use lazy loading, clarify that a Windows application that uses jpeg_mem_dest() or jpeg_mem_src() must use the DLL containing those functions at run time.  Other wordsmithing


git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@915 632fc199-4ca6-4c93-a231-07263d6284db
Fix several issues with SRPM generation:  (1) ensure that all relevant configure arguments get passed down to the configure command line in the generated spec file, (2) adjust the file manifest in the spec to accommodate the differing "age" version whenever the in-memory source/dest managers are used, and (3) fix an issue with the value of SO_MAJOR_VERSION passed down to the configure command line in the generated spec file (SO_MAJOR_VERSION has to remain pure, so we use a different variable to pass down the combined "current+age" value to libtool in Makefile.am.)


git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@916 632fc199-4ca6-4c93-a231-07263d6284db
New year, new copyright message


git-svn-id: svn://svn.code.sf.net/p/libjpeg-turbo/code/trunk@917 632fc199-4ca6-4c93-a231-07263d6284db