NOTE: Disabling LZ4 and LZO entirely prevents the libraries from
being loaded at all. This currently results in CISOv2 images that
partially load, but fail when an LZ4-compressed block is encountered.
We can't use standard pthread_once() here due to the use of member
functions. Instead, we're using a macro that simulates it, based on
the Windows version in pthread_once.c.
NOTE: Still using the standard pthread_once_t type, which is `long`
on Linux systems.
[librpthreads] CMakeLists.txt: Check for sched_yield().
pthread_yield() is deprecated as of glibc-2.34.
If sched_yield() isn't found, define it as pthread_yield().
This will make it so only one initialization is needed if using a single
libromdata.so load to read multiple PSP images.
NOTE: CisoPspDlopen isn't thread-safe at this point. Need to use
pthread_once() for initialization.
LZ4 is only used by CisoPspReader, so there's no need to load it on
startup on Linux systems. Instead, use dlopen().
Remove the various `#ifdef HAVE_LZ4` checks.
TODO: Show a warning if the image requires LZ4 but we don't have it.
For now, it just says the image couldn't be opened.
On Windows, we're switching from DelayLoad to LoadLibrary() for
consistency.
[libwin32common] DelayLoadHelper.h: Export rp_LoadLibrary().
This is used by CisoPspReader to load lz4.dll.
The exported version does not do a DLL whitelist check, whereas
the version used by the MSVC exception handler does.
Noticed this on my local system after updating from cURL 8.12 to 8.13:
$ /usr/libexec/rp-download -v sys/version.txt
URL: https://rpdb.gerbilsoft.com/sys/version.txt
Cache Filename: /home/user/.cache/rom-properties/sys/version.txt
Cache file for 'sys/version.txt' is already downloaded, but this cache key is set to download-if-newer.
SYSCALL TRAP: [amd64] recvmmsg()
Segmentation fault
This is what was causing the libpng crash in png_longjmp() on
Windows 10 in MSVC 2022 release builds.
See #451: libpng errors crash due to libpng setjmp/longjmp (Windows 10, release builds only)
Reported by @Masamune3210.
For both the char* version and the std::string version.
Code coverage change:
Before:
source files: 607
lines.......: 24.1% (11442 of 47453 lines)
functions...: 24.0% (910 of 3786 functions)
branches....: 17.0% (8352 of 49177 branches)
After:
source files: 607
lines.......: 24.1% (11450 of 47453 lines)
functions...: 24.1% (911 of 3786 functions)
branches....: 17.0% (8353 of 49177 branches)
CMake 4.0 drops compatibility with versions older than 3.5, and warns
that compatibility with < 3.10 will be dropped in a "future version".
CMake 3.30 previously warned about dropping support for older than
3.5, which was changed in 3.31 to older than 3.10.
This fixes a bunch of warnings similar to the following:
CMake Warning (dev) at src/kde/kf5/CMakeLists.txt:370 (INSTALL):
Policy CMP0177 is not set: install() DESTINATION paths are normalized. Run
"cmake --help-policy CMP0177" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
This warning is for project developers. Use -Wno-dev to suppress it.
Assume anything <=57 is Heisei, and >=58 (1983) is Shōwa.
NOTE: The FDS was released in 1986, but we'll allow for 1983 just in case
there was an FDS game in development in 1985. (Maybe the lower bound
should be 1985 instead...)
FIXME: The minigzip and minizip binaries are automatically built,
even though we use SET_EXTLIB_PROPERTIES(), which should exclude
them from ALL builds...
The Shift-JIS thing was incorrect, even with the U+0081 code point.
It's all UTF-8 that was incorrectly converted from cp1252 to UTF-16BE.
Also, remove a redundant string conversion that I was using earlier for
debugging purposes and is no longer needed.
Two types of mojibake are detected and fixed:
- UTF-8 parsed as cp1252
- Shift-JIS parsed as cp1252
For the latter case, utf16_to_cp1252() on Linux (and other systems that
use iconv) has been modified to handle five code points that iconv()
doesn't support: 0x81, 0x8D, 0x8F, 0x90, 0x9D.
TODO: Also do this for utf8_to_cp1252() and other cp1252 functions?
On Windows, WideCharToMultiByte() and MultiByteToWideChar() handle these
code points without any issues.
These three title updates now show a correct title:
TU_11LK1UV_0000004000000.0000000000081 (UTF-8 as cp1252)
Name: 'Dodonpachi Daifukkatsu Black Label Title Update #1'
Title: '怒首領蜂 大復活 Black Label'
TU_12501VG_0000004000000.0000000000101 (UTF-8 as cp1252)
Name: 'DREAM C CLUB Title Update #4'
Title: 'ドリームクラブ'
TU_15LG1UH_000000C000000.0000000000083 (Shift-JIS as cp1252)
Name: 'Circle of Students Title Update #1'
Title: '円卓の生徒'
Fixes#450: X360 - Non-Latin Titles appearing as mojibake
Reported by @Masamune3210.
Check the magic number before initializing libpng.
It seems there's something wrong with MSVC 2022 (17.6.5) that causes a
release build of libpng to crash when calling longjmp() on Windows 10.
If this is in fact a compiler bug, and upgrading the compiler fixes it,
then I'll need to switch away from my Windows 7 VM because MSVC 17.6 is
the last version to support Windows 7 as a build environment.
See #451: libpng errors crash due to libpng setjmp/longjmp (Windows 10, release builds only)
Reported by @Masamune3210.
.dol files aren't currently supported by rom-properties. shared-mime-info
is misidentifying them as image/vnd.microsoft.icon, which is clearly
wrong, so add this to fix the identification.
Expected MIME types:
- .png: image/png
- .jpg: image/jpeg
- .txt: text/plain
Not sure if this will make any real difference, but we might as well
set it anyway.
zlib is already checked earlier. On my system, since I have zlib-ng
installed system-wide, this check picks it up, and causes libromdata.so.6
to be linked to libz-ng.so.2.
Disabling the check removes that linkage.
NOTE: The Ubuntu packages for 2.5 and 2.5.1 are *not* linked to zlib-ng,
since Ubuntu doesn't have zlib-ng included by default.
Also, update _MODIFIED_MINIZIP.txt for 4.0.10. (Forgot to do this when
updating from 4.0.9 to 4.0.10.)
gcc-4.9 on Debian 8 doesn't support multi-line constexpr functions.
CONSTEXPR_MULTILINE enables constexpr for MSVC 2022 and gcc-5,
and later versions.
CONSTEXPR_MULTILINE_NO_MSVC enables constexpr for gcc-5 and later,
but not MSVC. Needed for functions that use intrinsics, which
(still) aren't marked as constexpr on MSVC.
The Unicode text printing on Windows via _fputts() was causing the
console output to lock up on Windows 7. Switching to libgsvt fixes it.
Code size difference: (64-bit Gentoo Linux, gcc-15.1.0, release build, no LTO)
text data bss dec hex filename
16247 1032 48 17327 43af GcnFstPrint [before]
19006 1160 80 20246 4f16 GcnFstPrint [after]
+2759 +128 +32 +2919 +b67 Difference
text data bss dec hex filename
15417 1016 48 16481 4061 WiiUFstPrint [before]
18210 1144 80 19434 4bea WiiUFstPrint [after]
+2793 +128 +32 +2953 +b89 Difference
The xgettext call in locale/CMakeLists.txt doesn't detect
QObjectDerivedClass::tr(). Because of this, we ended up missing
a few strings for translation.
[locale] Update with the missed strings.
