This makes it easier to read and reduces code size a bit.
Code size differences: (64-bit Gentoo Linux, gcc-11.2.0, release build, no LTO)
text data bss dec hex filename
16889 0 0 16889 41f9 basisu_astc_decomp.cpp.o [before]
16877 0 0 16877 41ed basisu_astc_decomp.cpp.o [after]
-12 0 0 -12 -c Difference
AppVeyor's MinGW-w64 build is showing -Wformat warnings that aren't
showing up locally. Unfortunately, I can't seem to find an equivalent
for `make -k` with CMake, so I'll have to keep pushing individual
fixes until I get it fully built.
Reference: https://fedoraproject.org/wiki/Format-Security-FAQ
-Werror=format-nonliteral is *not* enabled because there are some
legitimate uses of non-literal format strings.
Separated the warning flags into multiple variables.
Updated everything to build with this change.
These arrays don't have values that exceed 255, so there's no point
in wasting all the space.
Code size differences: (64-bit Gentoo Linux, gcc-11.2.0, release build, no LTO)
text data bss dec hex filename
23065 0 0 23065 5a19 basisu_astc_decomp.cpp.o [before]
16889 0 0 16889 41f9 basisu_astc_decomp.cpp.o [after]
-6176 0 0 -6176 -1820 Difference
Also enabled the following flags:
- large address aware
- high entropy VA (64-bit only)
- dynamic base
- nxcompat
For some reason, these weren't enabled when I built them before, which
broke when running ROM Properties from a network share on Windows 10
due to the "Prohibit Dynamic Code" policy. (Probably nxcompat.)
Also, strip the binaries in bin.i386/.
This was originally fixed in commit b243f47341.
([tinyxml2] Fix DLL installation in Windows packaging.)
However, it regressed when TinyXML2 was upgraded to 8.1.0 in
commit 05aed01ddf.
([tinyxml2] Updated to tinyxml2-8.1.0.)
The end result was the 32-bit TinyXML2 being installed in bin/,
and the 64-bit TinyXML2 not being installed at all. This resulted in
crashes, which shouldn't have happened either; this means something
is wrong with DelayLoad, so that will need to be fixed next.
Fixes#313: tinyxml2.dll isn't packaged correctly
Reported by @ccawley2011.
extlib\zstd\compress\zstd_lazy.c(1399): error C4703: potentially uninitialized local pointer variable 'dmsTagRow' used
extlib\zstd\compress\zstd_lazy.c(1407): error C4703: potentially uninitialized local pointer variable 'dmsRow' used
gcc-11.1 complained about uninitialized variables, and googletest has
-Werror specified:
In file included from ../../extlib/googletest/googletest/src/gtest-all.cc:42:
../../extlib/googletest/googletest/src/gtest-death-test.cc: In function ‘bool testing::internal::StackGrowsDown()’:
../../extlib/googletest/googletest/src/gtest-death-test.cc:1301:24: error: ‘dummy’ may be used uninitialized [-Werror=maybe-uninitialized]
1301 | StackLowerThanAddress(&dummy, &result);
| ~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
../../extlib/googletest/googletest/src/gtest-death-test.cc:1290:13: note: by argument 1 of type ‘const void*’ to ‘void testing::internal::StackLowerThanAddress(const void*, bool*)’ declared here
1290 | static void StackLowerThanAddress(const void* ptr, bool* result) {
| ^~~~~~~~~~~~~~~~~~~~~
../../extlib/googletest/googletest/src/gtest-death-test.cc:1299:7: note: ‘dummy’ declared here
1299 | int dummy;
| ^~~~~
cc1plus: all warnings being treated as errors
I tested a release build and it saved a total of 10,752 bytes.
On the other hand, it had a rather huge maintenance overhead, since I had
to ensure that all extlibs had __cdecl set up in the headers properly,
and this had to be redone on every update.
The i386 build of LZ4 on AppVeyor was failing in tests because of missing
stdcall symbols. I decided not to bother adding stdcall support to LZ4
and simply revert stdcall entirely.
I somehow missed these when updating zstd earlier. It only seemed to
break the MinGW-w64 builds, which is odd, since I would have expected
this to break every build in cases where we didn't have a system zstd...
https://github.com/nmoinvaz/minizip
NOTE: iconv support is disabled for now, since it isn't needed by any
of the test cases. It may be re-enabled later if minizip is needed for
the main program.
We're technically installing both the Debug and Release files, but only
one will exist at any given time, so it has to be OPTIONAL.
[libpng] CMakeLists.txt: Minor formatting improvements.
This broke the Mac OS X build:
In file included from /Users/travis/build/GerbilSoft/rom-properties/extlib/lz4/lib/lz4.c:110:
/Users/travis/build/GerbilSoft/rom-properties/extlib/lz4/contrib/cmake_unofficial/../../lib/lz4.h:119:1: error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes
LZ4LIB_API int LZ4LIB_CALL LZ4_versionNumber (void); /**< library version number; useful to check dll version */
^
/Users/travis/build/GerbilSoft/rom-properties/extlib/lz4/contrib/cmake_unofficial/../../lib/lz4.h💯22: note: expanded from macro 'LZ4LIB_API'
.# define LZ4LIB_API __declspec(dllexport) LZ4LIB_VISIBILITY
^
- TextOut: Added CRLF linebreak options, which are needed for
copying to clipboard on Windows.
[rapidjson] prettywriter.h: Added a CRLF linebreak option.
The JSON output code will be rewritten to use rapidjson, which will allow
us to add more stuff without having to worry if the resulting text has
the correct formatting.
This adds around 20 KB to the compiled binary.
I chose MiniLZO instead of regular LZO because we only need to be able to
decompress LZO1X blocks.
[libromdata] CisoPspReader: Don't call lzo_init() if this JISO isn't
actually using LZO. Otherwise, if the DLL is missing on Windows, the
program will crash.
This should fix the MinGW-w64 build:
[ 16%] Building RC object extlib/lz4/contrib/cmake_unofficial/CMakeFiles/lz4_shared.dir/__/__/visual/VS2017/liblz4-dll/liblz4-dll.rc.obj
C:\projects\rom-properties\extlib\lz4\visual\VS2017\liblz4-dll\liblz4-dll.rc:6:21: fatal error: verrsrc.h: No such file or directory
.#include "verrsrc.h"
^
compilation terminated.
C:\mingw-w64\i686-6.3.0-posix-dwarf-rt_v5-rev1\mingw32\bin\windres.exe: preprocessing failed.
Main changes:
- gettext now has wbindtextdomain() on Windows, so we can remove our
custom Unicode patch.
- The 64-bit version seems to always build DllMain from the relocatable
package, even though we're disabling that...
New patches:
122-Use-LF-as-newline-in-envsubst.patch
- From: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gettext
- Use LF as newlines instead of CRLF.
1002-dcigettext-c-include-wchar-h.patch:
- #include <wchar.h> for _wgetcwd().
1003-gettextsrc-exports-missing-formatstring-ruby.patch:
- Fix a missing export for formatstring_ruby, which fixes an undefined
__imp_* symbol error.
1004-gettext-runtime-disable-iconv.patch:
- Disable iconv support in gettext runtime so we don't need to bundle
iconv.dll in the final package.
- Was applied previously, but I forgot to include it as a patch.
It turns out we need it because other modules are compiled with /Gz,
even if zstd isn't.
FIXME: Compiling zstd with /Gz fails due to C2373 type redefinition
errors, which doesn't make any sense...
Otherwise, the travis-ci build fails because BUILD_SHARED_LIBS is OFF
here, so CMake tries building it as a static library, and then fails
because the INSTALL() rule lacks an ARCHIVE target.
- TARGET_INCLUDE_DIRECTORIES(): Needs to be PUBLIC, not INTERFACE.
Otherwise, rc.exe can't find zstd.h.
- verrsrc.h: Added VS_FF_DEBUG, which is used by libzstd-dll.rc but
wasn't present in the original version upstream.
- Remove "/Ob0 /Od /RTC1" from debug flags. In particular, "/Od" and
"/RTC1" conflict with each other:
cl : Command line error D8016: '/O2' and '/RTC1' command-line options are incompatible
- Add "/Ob2" to debug CFLAGS.
- Set -DZSTD_DLL_EXPORT when building the DLL. Otherwise, symbols aren't
exported and the import library isn't built.
- Set -DZSTD_DLL_IMPORT when importing the DLL. This isn't strictly
necessary, but it does reduce some overhead.
- Install the PDB files. (Copied from zlib.)
MiniZip 2.10.0 added support for zstd as a compression method, so we
should support it.
Note that a system version of zstd is preferred on Linux systems.
Enabled the MiniZip test tools for manual builds only. Info-ZIP hasn't
been updated in a while, so I'm going to use the MiniZip test tools to
compress ZIP archives using zstd.
Enabled MiniZip compression in order to compress stuff using the minizip
test program.
mz_strm_zstd.c: FIXME: Compression level doesn't work. Hard-coded the
maximum compression level for now.
The variables are CMAKE_PROJECT_VERSION* for the top-level version
PROJECT_VERSION_* is set if a subproject sets a version number.
- CMP0048 is needed in order to use VERSION. This might be implied by
using CMAKE_MINIMUM_REQUIRED(), but we'll explicitly specify it anyway.
- Set policies before calling PROJECT().
- Update the Win32 DO_SPLIT_DEBUG() code to use PROJECT_VERSION_*
variables if set, or CMAKE_PROJECT_VERSION* if not.
This should fix the Win32 build.
This fixes a regression from commit a1a2e0895c.
(Set all projects to require CMake 3.0.)
- Added language specifications.
- Set the top-level project version in the PROJECT() call.
- Set CMP0063 to NEW if it's available. This enables the symbol
visibility presets on *all* target types, not just shared libraries,
module libraries, and executables with ENABLE_EXPORTS set.
Compiled on Ubuntu 20.04 using MinGW-w64 with gcc-9.3.0-7ubuntu1+22~exp1ubuntu4.
Some changes:
- The libraries are significantly smaller than before. Not sure what
really changed...
- The .def files no longer have ordinals.
MinGW-w64 defines FSCTL_GET_REPARSE_POINT in winioctl.h (or a file
included by it), so we end up with a redefinition warning.
C:\projects\rom-properties\extlib\minizip\mz_os_win32.c:23:0: warning: "FSCTL_GET_REPARSE_POINT" redefined
. # define FSCTL_GET_REPARSE_POINT CTL_CODE(FILE_DEVICE_FILE_SYSTEM, 42, METHOD_BUFFERED, FILE_ANY_ACCESS)
In file included from C:\projects\rom-properties\extlib\minizip\mz_os_win32.c:22:0:
C:/mingw-w64/i686-6.3.0-posix-dwarf-rt_v5-rev1/mingw32/i686-w64-mingw32/include/winioctl.h:1280:0: note: this is the location of the previous definition
. #define FSCTL_GET_REPARSE_POINT CTL_CODE(FILE_DEVICE_FILE_SYSTEM,42,METHOD_BUFFERED,FILE_ANY_ACCESS
ffs() is not declared in headers, even though it's a gcc built-in.
extlib/libmspack-xenia/xenia_lzx.c: In function 'bit_scan_forward':
extlib/libmspack-xenia/xenia_lzx.c:39:10: warning: implicit declaration of function 'ffs' [-Wimplicit-function-declaration]
39 | int i = ffs(v);
| ^~~
extlib/libmspack-xenia/xenia_lzx.c:39:14: warning: 'ffs' argument 1 promotes to 'uint32_t' {aka 'unsigned int'} where 'int' is expected in a call to built-in function declared without prototype [-Wbuiltin-declaration-mismatch]
39 | int i = ffs(v);
| ^
<built-in>: note: built-in 'ffs' declared here
https://github.com/nmoinvaz/minizip
This includes a potential buffer overflow fix in mz_os_win32.c when
determining the pathname of kernel32.dll. We don't actually need it,
since kernel32.dll is always loaded, so use GetModuleHandle() instead.
Upstream changes:
[CPU] Use window size for LZX ref_data_size
71780838f0
[CPU] Properly clear LZX window
c213f7d7a3
Added xe::bit_scan_forward, referenced in these commits:
[CPU] Minor LZX code cleanup.
29665ae79c
[CPU] Fix lzx_decompress misuse of xe::bit_count.
e14639c6c0
There's also a fix for the non-Windows implementation (off-by-one).
Fixes PVS-Studio V127 (Med): An overflow of the 32-bit 'window_bits'
variable is possible inside a long cycle which utilizes a memsize-type
loop counter.
We need to install in ${INSTALL_BIN_DIR}, not ${CMAKE_INSTALL_BINDIR}.
Otherwise, it ends up in bin/ instead of i386/ or amd64/.
[libpng] Use ${INSTALL_BIN_DIR} for the Framework destination. This will
be used if I ever get any Mac OS X frontends done (besides rpcli).
This fixes issue #194: package.cmd: tinyxml2.dll isn't copied over correctly.
Main changes:
- Color A and Color B now share an opaque flag.
- Color B: The low bit of alpha is always 1, not 0.
- Tiles are stored in linear order, not Morton order.
To make it easier to support both formats with minimal changes, the
original PVRTC code has been changed to use templated functions.
Simple non-templated wrapper functions are provided for external use.
PowerVR3, KhronosKTX: Handle PVRTC-II. Note that there's no FourCC
defined for DDS, so we're not updating DirectDrawSurface.
TODO:
- The Hard transition flag isn't supported. PVRTexToolCLI didn't use the
hard transition flag when creating the test images.
[libromdata/tests] ImageDecoderTest: Added some PVRTC-II test images.
Based on tctest's example.png. Note that the PVRTC-II test images are
the full 512x512, whereas the PVRTC-I test image was 256x256.
We have our own ETC1 decompression code, which might be somewhat faster
than PowerVR's due to use of lookup tables. (Maybe I should benchmark
this later...)
It seems that the R and B channels are backwards, so we'll need to fix
that next. Other than that, both 2bpp and 4bpp decoding seems to work.
(A lot better than my terrible attempt, at least.)
[cmake] options.cmake: Added an option for PVRTC. The code is licensed
under the MIT license, but we might as well provide an option for it
because it's third-party code instead of my own code.
TODO:
- Fix R/B channel ordering.
- PVRTC-II decoding?
- Add PVRTC decoding to KTX and DDS.
This now has the correct 32-bit DLL and supporting libraries.
The __imp_libintl_version symbol is present again.
This fixes a 32-bit Windows build regression from
commit bc41a4e845.
([gettext.win32] Recompiled gettext-0.20.1.)
Compiled on Ubuntu 19.10 using MinGW-w64 with gcc-9.2.1-9ubuntu1+22~exp1ubuntu2.
The previous build was compiled on Ubuntu 19.04 using MinGW-w64
with gcc-8.3.0.
Some changes:
- The i386 .def file no longer has __imp_libintl_version.
- The .debug files are no longer compressed. I'm not sure how many
Windows tools support compressed debug files.
This should have been added before, but apparently it wasn't added to
the repository due to the .gitignore rule, and I forgot to specify the
--force option. Oh well.
It was only used on Windows, and since we're using GDI+ for JPEG decoding
on Windows now, it's not needed.
If a Mac OS X UI frontend is added at some point, I'll probably use the
system JPEG decoder instead of re-adding libjpeg-turbo.
It's not working properly on AppVeyor, even though we did set
_WIN32_WINNT=0x0600. (Then again, maybe it just needed winioctl.h...)
Removed the _WIN32_WINNT definition, since it's no longer needed.
[librpbase] TextFuncs.hpp:
- Don't #include "TextFuncs_libc.h". Anything that uses strnlen() or
memmem() has to include this header file directly.
- Moved RP_WIS16 from config.librpbase.h to TextFuncs.hpp. This wasn't
actually configured by cmake; it's set on Windows and unsaet on
everything else.
[libromdata] WiiWAD.cpp: #include "librpbase/config.librpbase.h"
for ENABLE_DECRYPTION.
PROJECT_NAME() was removed in commit 9ea341f40c:
[minizip] Updated to v2.8.4 from the MiniZip fork.
...and re-added with `minizip` in commit 9ea341f40c:
[minizip] CMakeLists.txt: Restore target_include_directories() changes.
Since this didn't update the main extlib CMakeLists.txt, this broke the
extlib properties for minizip. In particular, EXCLUDE_FROM_ALL wasn't
being set, so minizip was being built even when it wasn't needed.
Compiled on Ubuntu 19.04 using MinGW-w64 with gcc-8.3.0.
Some patches were dropped:
- 05-always-use-libintl-vsnprintf.mingw.patch: Doesn't apply cleanly
and isn't needed.
- 09-asm-underscore-mingw.patch: Merged upstream.
All other patches were applied, though some manual adjustments were
needed for a few patches, including the ctype/unistd include patch,
06-dont-include-ctype-after-gnulibs-wctype.mingw.patch.
Removed ini_parse_w(), since this should be handled by the caller.
[librpbase] ConfReader.cpp: On Windows, use _wfopen() to open the file
using a Unicode pathname, then use ini_parse_file() to parse the opened
INI file.
This caused the Windows build to fail due to use of functionality
added in Windows 8 (CERT_FIND_HAS_PRIVATE_KEY) that isn't available
due to the WINVER and _WIN32_WINNT settings.
We don't need encryption enabled for rom-properties, anyway.
https://github.com/nmoinvaz/minizip
[libromdata/tests] CMakeLists.txt: MiniZip now uses the target name
'minizip' instead of 'libminizip'.
[extlib] CMakeLists.txt: MiniZip's options are now prefixed with "MZ_".
This is a stripped-down version of libmspack containing only the necessary
functionality for Xbox 360 executables.
Xenia commit: e706cf0d5413c31b7e80a50411cc88cc7c71af30
License: LGPLv2.1
config.h.in: Modified for cmake; removed unnecessary checks.
debian/copyright: Added copyright information.
cmake/options.cmake: Added an ENABLE_LIBMSPACK option. (default is ON)
FIXME: Building tinyxml2 as a static library fails on my system:
/usr/bin/objcopy: illegal pathname found in archive member: /home/david/p/m/lib/../extlib/tinyxml2/CMakeFiles/tinyxml2.dir/tinyxml2.cpp.o
This seems to be a binutils security fix for CVE-2014-9447.
Unfortunately, cmake ends up using the full pathname in the static
library, which has a '..' because of the custom lib path.
https://github.com/nmoinvaz/minizip
[extlib] CMakeLists.txt: Define more options to ensure they have the
correct settings, since the option() statements in MiniZip's
CMakeLists.txt have been disabled.
- `inline` isn't defined in C mode in MSVC 2010 and 2013.
(It might be in 2015 and 2017?)
- main() must be `__cdecl`, but we're defaulting to `__stdcall`
in 32-bit builds.
- myfileno(): Added a missing semicolon.
This broke the travis-ci build:
/usr/bin/ld: ../../../lib/../extlib/unice68/CMakeFiles/unice68_lib.dir/unice68_unpack.c.o:
relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
../../../lib/libunice68.a: error adding symbols: Bad value
I didn't see this locally because I was only building rpcli when testing
the SNDH unice68 functionality.
This significantly reduces the size of the test executables.
This can be done more easily on Windows than on other platforms because
Windows includes the program's directory as part of the DLL search path
by default.
NOTE: I was originally trying to fix a linkage issue with
g_linked_ptr_mutex that was showing up when building on MSVC 2010,
but that seems to have disappeared by itself...
References for the linkage issue:
- https://github.com/google/googletest/issues/292
- https://github.com/ornladios/ADIOS2/pull/477
- d9657bda86
Apparently Windows 7 without SP1 has O/S support for XSAVE but not for
YMM registers, and this exposed a bug in our usage of xgetbv. The test
instruction will set ZF only if none of the bits match between the two
operarands, so in effect, we were enabling AVX2 instructions if the O/S
supported XSAVE and the CPU supported AVX2 but the O/S only supported
XMM registers. This bug was not exposed on, for instance, Windows XP or
RHEL 5 because those O/S's do not support XSAVE.
Upstream commit:
d5f281b734
This fixes the build of unice68.
The unice68 executable can now be built in tree for testing purposes,
but it isn't built or installed as part of the normal build.
This will be used to decompress Atari ST SNDH files.
Note that unice68 is GPLv3, so there's a compile-time option to
disable it.
TODO: Make it a DLL/SO instead and use dlopen().
Tests are all executables, so none of the libraries need to be PUBLIC.
External libraries should not be exporting their dependencies if they
aren't needed.
Major changes include AVX2 optimizations and a vastly improved
CMakeLists.txt that works on all platforms.
This includes the JPEGCALL changes required for /Gz on 32-bit MSVC.
libjpeg-turbo.rc: Moved from sharedlib/ to win/.
https://github.com/nmoinvaz/minizip
[extlib] CMakeLists.txt: Disabled MiniZip compression. We're currently
only using it for decompression, so there's no need to build the
compression code, which wastes time and disk space.
- #include "config.librpbase.h" in order to define HAVE_ZLIB, which tells
mz_compat.h to #include <zlib.h>.
- #include <zlib.h> manually anyway.
- unz_file_info64.uncompressed_size is uint64_t, not uLong.
libintl.h: Disabled libgnuintl wrappers for printf() functions.
We don't need to use the GNU versions for anything, and it causes problems
if libgnuintl-8.dll is unavailable, since we can't use printf() to print
an error message in that case.
- Redefine snprintf() as _snprintf() on older versions of MSVC.
See c99-compat.msvcrt.h.
DelayLoadHelper.cmake: Delay-load libgnuintl-8.dll.
DelayLoadHelper.h: Added a 1-argument macro.
[win32] DllMain.cpp, DllGetClassObject() Fail if libgnuintl-8.dll can't
be loaded.
[rpcli] rpcli.cpp: Print an error message if libgnuintl-8.dll can't be
loaded.
- TODO: Print the program information.
[win32] ConfigDialog.cpp: Show an error message if libgnuintl-8.dll
can't be loaded.
- TODO: Move this to rp-config.c? Doing that will result in no error
message if rundll32.exe is used, though...
This should be the last thing needed for issue #122:
[win32] Build and link in GNU gettext or equivalent
This will fix some of the unit tests that aren't running because they
can't find libtinyxml2.6.dylib.
FIXME: #include <fstream> is still causing fseeko()/ftello() issues in
bmp.cpp, but not rpcli.cpp or properties.cpp...
loadmsgcat.c: Convert the filename from UTF-8 to UTF-16, then use
_wopen() to open the file.
[libi18n] i18n.c: Convert the filename to UTF-8 instead of ANSI.
gettext now works on Windows if non-ANSI characters are present in
rom-properties' path.
The gettext libraries and executables were built on Ubuntu 18.04 using
MinGW-w64 with gcc-7.3.0.
iconv support has been disabled for the runtime, but it's still needed
for some of the build executables. For that, we're using win-iconv, which
is an iconv wrapper that uses the Windows API. [1]
In addition, several patches from the official MinGW package repository
were applied to gettext-0.19.8.1 in order to get it to build correctly
for Windows. [2]
TODO:
- Test packaging to ensure the correct DLL is packaged.
- Test bindtextdomain() to determine if it supports Unicode. If it
doesn't, then another patch will be needed.
[1] https://github.com/win-iconv/win-iconv
[2] https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gettext
This fixes NASM detection on Win64 if 64-bit NASM is installed and
hasn't been added to PATH.
This should fix issue #79. (cmake can't find NASM on Win 10)
https://github.com/nmoinvaz/minizip
Note that this release removes the AES-NI code, though we weren't
enabling encryption in the first place.
There's also some changes to use add_compile_options() and the
POSITION_INDEPENDENT_CODE property instead of manually setting
CMAKE_C_FLAGS and "-fpic -fPIC".
TODO: Use POSITION_INDEPENDENT_CODE in other libraries?
This adds INI_START_COMMENT_PREFIXES to allow changing start-of-line
comment characters. It also adds dynamic line buffer reallocation,
though it's disabled in rom-properties.
https://github.com/nmoinvaz/minizip
NOTE: The changes include removing the 16-bit size limitation, which only
really applies when building for DOS, but it was incorrectly set for all
platforms. I'm not going to change anything that uses it right now, though.
MiniZip already checks for libbsd, but doesn't fail if it's not found.
Added a failure if it's not found, and removed the broken FIND_PACKAGE()
call, which doesn't work because there's no CMake module for it.
https://github.com/nmoinvaz/minizip
An additional fix for unzOpen() hasn't been merged yet:
https://github.com/nmoinvaz/minizip/pull/207
Note that MiniZip 2.x uses UTF-8 for filenames on all platforms,
including Windows. I'm keeping the fill_win32_filefunc64W() call
in place just in case, though.
Bzip2, LZMA, ZipCrypto, and AES support are all disabled for now,
but the sources are still included.
I'm going to try using stdcall to build the 32-bit version, which should
save a bit of space and improve performance slightly. However, in order
to preserve ABI compatibility, exported C functions must have __cdecl,
and libjpeg-turbo doesn't do this.
JPEGCALL expands to __cdecl on MSVC and nothing on other compilers.
JPEGCALL has been added to function declarations and function pointers
in order to fix compilation with /Gz on MSVC.
The eXIf functions added in 1.6.31 were broken, so two new functions
were added and the old ones stubbed. This shifts the ordinals for APNG
over by two again.
MSVC didn't properly support C99 until MSVC 2015, so the extra ';' makes
MSVC think that we've started adding statements. Hence, it fails because
there are still some variable declarations after it.
Commit: d507f2e7e8b771a76f4eb96d5c5d4dee50988196
Merge pull request #124 from Coeur/patch-3
The original MiniZip hasn't been updated in quite a while. This fork has
a lot of new functionality, including support for AES (though we aren't
using it). It also has some of the stuff I manually added before,
including CMakeLists.txt and Windows fixes.
FIXME: It's not compiling on MSVC 2010, probably due to declaring
variables after statements.
Note that two new functions were added to the original libpng, so the
ordinals for APNG were shifted over by two. This shouldn't be a problem,
since programs should be accessing functions by name instead of by
ordinal in 2017.
Among other things, this update adds in reporting of the location oc
parsing errors, which was present in the original TinyXML but not
earlier versions of TinyXML2.
This adds a new function ini_parse_string(), which parses an INI file
from a loaded C string buffer.
Local changes, including ini_parse_w(), have been preserved.
This didn't seem to actually cause any problems, but it could result in
the statically-linked zlib being used in test suites in addition to the
DLL zlib.
Rebased CMakeLists.txt on the original TinyXML2 CMakeLists.txt,
but with lots of stuff disabled and some changes.
- Disable installation of everything except the DLL.
- Disable testing.
- Set TINYXML2_IMPORT as an interface definition when building
as a DLL.
- Remove TINYXML2_EXPORT in the static library build, which didn't
work anyway due to a typo.
- Added a debug postfix for debug DLLs.
- Disabled MSVC configuration that's alread yset in the platform
configuration.
- Added other MSVC options, including split debug settings.
