KDE4's CMake files overwrite these variables with its own flags, which
breaks the debug build due to the use of GLIBCXX debug iterators:
[ 52%] Linking CXX shared module ../../../lib/rom-properties-kde4.so
CMakeFiles/rom-properties-kde4.dir/__/rp_create_thumbnail.cpp.o: In function `rp_create_thumbnail2':
src/kde/rp_create_thumbnail.cpp:194: undefined reference to `LibRpBase::RpPngWriter::write_tEXt(std::vector<std::pair<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const&)'
CMakeFiles/rom-properties-kde4.dir/__/RomDataView.cpp.o: In function `RomDataViewPrivate::updateMulti(unsigned int)':
src/kde/RomDataView.cpp:793: undefined reference to `LibRpBase::RomFields::getFromStringMulti(std::map<unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > const*, unsigned int, unsigned int)'
CMakeFiles/rom-properties-kde4.dir/__/RomDataView.cpp.o: In function `RomDataViewPrivate::initAgeRatings(QLabel*, LibRpBase::RomFields::Field const&)':
src/kde/RomDataView.cpp:719: undefined reference to `LibRpBase::RomFields::ageRatingsDecode[abi:cxx11](std::array<unsigned short, 16u> const*, bool)'
CMakeFiles/rom-properties-kde4.dir/__/config/CacheCleaner.cpp.o: In function `CacheCleaner::run()':
src/kde/config/CacheCleaner.cpp:98: undefined reference to `LibRpFile::recursiveScan(char const*, std::forward_list<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char>, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, unsigned char> > >&)'
collect2: error: ld returned 1 exit status
src/kde/kde4/CMakeFiles/rom-properties-kde4.dir/build.make:1357: recipe for target 'lib/rom-properties-kde4.so' failed
The debug build now uses std::debug:: variants of the containers, so we
need to preserve the GLIBCXX defines properly.
Assertions are enabled for libstdc++ (gcc) and libc++ (llvm/clang).
Debug mode is enabled for libstdc++ only.
libc++'s hardened mode is also enabled.
libstdc++'s debug mode has already helped find a few bugs:
- GLenumStrings.cpp: sRGB PVRTC v1 was in the wrong place.
- AmiiboData.cpp: Searching for character variants was incorrect.
Not enabled for Release builds, since the assertions cause the program
to crash with SIGABRT.
gcc-7.1 and later print a lot of annoying warnings on armhf whenever
passing an iterator to a function:
In file included from /usr/include/c++/13/memory:69,
from rom-properties/src/librptexture/stdafx.h:23,
from rom-properties/build/src/librptexture/CMakeFiles/rptexture.dir/cmake_pch.hxx:7,
from <command-line>:
/usr/include/c++/13/bits/stl_uninitialized.h: In function ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = move_iterator<_KTX2_Mipmap_Index*>; _ForwardIterator = _KTX2_Mipmap_Index*; _Allocator = rp::default_init_allocator<_KTX2_Mipmap_Index, allocator<_KTX2_Mipmap_Index> >]’:
/usr/include/c++/13/bits/stl_uninitialized.h:344:5: note: parameter passing for argument of type ‘std::move_iterator<_KTX2_Mipmap_Index*>’ changed in GCC 7.1
344 | __uninitialized_copy_a(_InputIterator __first, _InputIterator __last,
| ^~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/13/bits/stl_uninitialized.h:344:5: note: parameter passing for argument of type ‘std::move_iterator<_KTX2_Mipmap_Index*>’ changed in GCC 7.1
/usr/include/c++/13/bits/stl_uninitialized.h: In function ‘_ForwardIterator std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = _KTX2_Mipmap_Index*; _ForwardIterator = _KTX2_Mipmap_Index*; _Allocator = rp::default_init_allocator<_KTX2_Mipmap_Index, allocator<_KTX2_Mipmap_Index> >]’:
/usr/include/c++/13/bits/stl_uninitialized.h:399:9: note: parameter passing for argument of type ‘std::move_iterator<_KTX2_Mipmap_Index*>’ changed in GCC 7.1
398 | return std::__uninitialized_copy_a
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~
399 | (_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(__first),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
400 | _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(__last), __result, __alloc);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Set QT_NO_CREATE_VERSIONLESS_TARGETS to disable Qt::Core. Otherwise,
CMake ends up trying to create Qt::Core twice, even when building for
KF6 only and not KF5+KF6:
CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6Core/Qt6CoreVersionlessTargets.cmake:42 (message):
Some (but not all) targets in this export set were already defined.
Targets Defined: Qt::Core
Targets not yet defined: Qt::CorePrivate
Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/Qt6Core/Qt6CoreConfig.cmake:68 (include)
/usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:174 (find_package)
cmake/libs/RP_FindQt6andKF6.cmake:34 (FIND_PACKAGE)
src/kde/kf6/CMakeLists.txt:6 (FIND_QT6_AND_KF6)
- Don't specify the minimum KF6 version, because that's breaking for
some reason.
-- Could NOT find KF65.248.0 (missing: KF65.248.0_DIR)
-- Could NOT find KF65.248.0: found neither KF65.248.0Config.cmake nor kf65.248.0-config.cmake
CMake Error at /usr/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find KF6 (missing: 5.248.0) (found version "6.6.0")
Call Stack (most recent call first):
/usr/share/cmake-3.30/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
/usr/share/ECM/find-modules/FindKF6.cmake:93 (find_package_handle_standard_args)
cmake/libs/RP_FindQt6andKF6.cmake:78 (FIND_PACKAGE)
src/kde/kf6/CMakeLists.txt:6 (FIND_QT6_AND_KF6)
(cherry picked from commit cb507652cb)
Conflicts:
debian/changelog
Enable it for both debug and release if using 10.0 or later.
This fixes an issue when running package.cmd that caused
InitPropVariantFromUInt16() to not be detected correctly when using
the Windows 7 SDK. (/permissive- was only enabled for debug builds,
but MSVC builds are technically debug and release, so it got enabled
in the InitPropVariantFromUInt16() check.)
These errors occurred without this fix:
c:\program files (x86)\microsoft sdks\windows\v7.1a\include\objbase.h(239): error C2760: syntax error: unexpected token 'identifier', expected 'type specifier'
c:\program files (x86)\microsoft sdks\windows\v7.1a\include\gdiplusheaders.h(891): error C4596: 'EmfToWmfBits': illegal qualified name in member declaration
c:\program files (x86)\microsoft sdks\windows\v7.1a\include\gdiplusstringformat.h(220): error C4596: 'GetTrimming': illegal qualified name in member declaration
TODO: Setting up KCrash would be useful, but DrKonqi shows a button to
report bugs to bugs.kde.org, which doesn't help us.
FIXME: Fix up the KLocalizedString versions for KDE4. (Or remove KDE4...)
[cmake/libs] RP_FindQt?andKF?.cmake: Find KCrash.
They haven't been experimental for quite a while.
Note that the GTK 4.x property model has far less functionality than
the property page, but that's a Nautilus limitation, so there's not
much that I can do about it.
Specify -DENABLE_NIXOS=ON to enable the workarounds.
- Using CMAKE_INSTALL_PREFIX in paths causes a double-path issue.
This only seems to happen on NixOS.
- std::locale's constructor ends up calling getdents64(), so this
syscall needs to be whitelisted. Only on NixOS though, since other
Linux distros don't need it...
Fixes#406: Building on NixOS returns "invalid system call"
Reported by @Whovian9369.
Nemo uses a GObject interface for this, whereas Caja uses a file.
FIXME: Caja shows the same description for both the property page and the
menu extensions. Either figure out a way to disambiguate them, or combine
the two plugins into a single plugin with multiple interfaces.
Available in clang, but not gcc (as of 14.2).
This ensures that header files (including .cpp files used with #include)
do not have global `using` statements.
NintendoDS_p.hpp: Removed unnecessary `using namespace` statements.
Removed global `using` statements from TCreateThumbnail.cpp and
TImageTypesConfig.cpp. Functions now have localized `using` statements.
Updated calling files to add `using` statements where necessary.
TImageTypesConfig.cpp: Also add a static_assert() for conf_imageTypeNames[].
FIXME: The generated moc files for OverlayIconPluginKF5 and
OverlayIconPluginKF6 both have `using namespace` directives, which
causes clang to fail due to -Werror=header-hygiene.
NETTLE_FOUND may be used to determine if libnettle should be
linked to other libraries and/or executables.
This fixes a regression from commit 22189ea4db.
([cmake] CheckNettle2or3.cmake: Convert the macro to a function.)
Otherwise, encryption will be disabled, even if Nettle is available.
This fixes a regression from commit 22189ea4db.
([cmake] CheckNettle2or3.cmake: Convert the macro to a function.)
Besides the filename and path changes, these changes were needed:
- Tracker 3.3.0-alpha added a function tracker_file_get_content_identifier(),
which is used for the content identifier. I'm only calling this function
if we're using API version 3. (TODO: Only for 3.3.0 or later, maybe.)
- tracker_file_get_content_identifier() is part of libtracker-miners-common,
which is statically linked into every extractor. As such, we can't simply
dlsym() the function from libtracker_extract. (We *could* get it from one
of the existing extractors, since they're exporting all of the symbols,
but that's an implementation detail that could change later.)
- tracker-file-utils.c implements tracker_file_get_content_identifier().
This file requires libblkid and (optionally) BTRFS_IOC_INO_LOOKUP.
CMakeLists.txt now checks for those and links in libblkid.
- Add libblkid to other relevant files, plus FindBlkid.cmake.
- Rename the .rule files to 14- so they take precedence over tracker-3's
own 15-executable.rule and 15-games.rule.
On my system, which has Thunar GTK3 but not GTK2, this was causing
libunixcommon's default GTK2 plugin search to look at:
/usr//usr/lib/thunarx-2/rom-properties-xfce.so
The correct path on here is:
/usr/lib64/thunarx-2/rom-properties-xfce.so
For some reason, something in KF5 and/or KF6's CMake modules (or maybe
part of ECM?) is setting CMAKE_INSTALL_LIBDIR=/usr/lib, which results
in the full path being /usr//usr/lib. That's obviously wrong.
Preserve CMAKE_INSTALL_LIBDIR before and after to ensure that it isn't
messed up by the KF5/KF6 CMake modules.
TODO: Convert RP_FindQt?andKF?.cmake into functions?
It doesn't link yet, but it compiles and it's almost there.
Changes:
- Use CPU architecture "wasm32".
- Disable split debug information.
- Disable libromdata.so.
- Don't build rp-download right now instead of failing with a fatal error.
FIXME: rpcli.js is failing to link:
[parse exception: attempted pop from empty stack / beyond block start boundary at 1177738 (at 0:1177738)]
Fatal: error in parsing input
Copy/paste error. Oops.
This fixes a regression from commit cb408e8351.
([cmake] Very basic support for PowerPC.)
This was commit on July 4, 2022, and affects v2.0 - v2.3.
It's not likely that anyone would notice, though...
gcc.cmake sets `-Werror=return-type`, which breaks FindIconv.cmake's
test code. Strangely, this is only causing problems when testing with
my Debian 8 PowerPC VM...
Performing C SOURCE FILE Test Iconv_IS_BUILT_IN failed with the following output:
Change Dir: build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/ninja" "cmTC_3ad47"
[1/2] Building C object CMakeFiles/cmTC_3ad47.dir/src.c.o
FAILED: /usr/bin/cc -Wall -Wextra -Wno-multichar -Werror=return-type
-Werror=format -fstrict-aliasing -Werror=strict-aliasing -fno-common
-fno-math-errno -Werror=implicit-function-declaration -fstack-protector-strong
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-include build/src/config.libc.h -include src/compiler-compat.h
-DIconv_IS_BUILT_IN -o CMakeFiles/cmTC_3ad47.dir/src.c.o -c src.c
src.c: In function ‘main’:
src.c:11:7: error: control reaches end of non-void function [-Werror=return-type]
}
^
cc1: some warnings being treated as errors
ninja: build stopped: subcommand failed.
Source file was:
. #include <stddef.h>
. #include <iconv.h>
int main() {
char *a, *b;
size_t i, j;
iconv_t ic;
ic = iconv_open("to", "from");
iconv(ic, &a, &i, &b, &j);
iconv_close(ic);
}
Disable it on other CPU architectures.
This fixes IFUNC detection on e.g. ARM64, though we're not currently
using IFUNC for anything other than i386/amd64 instruction sets.
EXECUTE_PROCESS() has been around since at least 3.0, and EXEC_PROGRAM()
is deprecated as of 3.28:
CMake Warning (dev) at cmake/cmake_uninstall.cmake:12 (EXEC_PROGRAM):
Policy CMP0153 is not set: The exec_program command should not be called.
Run "cmake --help-policy CMP0153" for policy details. Use the cmake_policy
command to set the policy and suppress this warning.
Use execute_process() instead.
We don't need to check errno for any math functions, and this prevents
certain inlining optimizations. In particular, lrintf() can't be inlined
if we don't specify this, even though glibc's documentation says that
its lrintf() implementation doesn't set errno.
Assembly comparison of manual truncation vs. lrintf() with
-fno-math-errno:
amd64:
- Manual: cvttss2si
- lrintf(): cvtss2si (note the single t)
i386 with SSE disabled:
- Manual: fistp with control word manipulation
- lrintf(): fistp without control word manipulation
Presumably the control word on manipulation changes the rounding mode.
lrintf() without errno doesn't change the rounding mode and relies on
the default rounding, which matches amd64.
TODO: MSVC equivalent, if available.
[libromdata] Nintendo3DSFirm: Fix a strict aliasing error on Ubuntu 16.04. (gcc-5.4.0)
In file included from src/libromdata/stdafx.h:62:0,
from src/libromdata/Handheld/Nintendo3DSFirm.cpp:9:
src/libromdata/Handheld/Nintendo3DSFirm.cpp: In member function ‘virtual int LibRomData::Nintendo3DSFirm::loadFieldData()’:
src/libromdata/Handheld/Nintendo3DSFirm.cpp:369:97: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
const uint32_t first4 = be32_to_cpu(*(reinterpret_cast<const uint32_t*>(firmHeader->signature)));
^
src/libromdata/../librpcpu/byteswap_rp.h:63:52: note: in definition of macro ‘__swab32’
# define __swab32(x) ((uint32_t)__builtin_bswap32(x))
^
src/libromdata/Handheld/Nintendo3DSFirm.cpp:369:27: note: in expansion of macro ‘be32_to_cpu’
const uint32_t first4 = be32_to_cpu(*(reinterpret_cast<const uint32_t*>(firmHeader->signature)));
^
cc1plus: some warnings being treated as errors
The path was changed to a common KIO directory in 5.85.
rom-properties-kf5.install: Add the ${SERVICES_INSTALL_DIR} entry, and
also remove the KIO install entry, since that was split out into the
rom-properties-kio-servicemenus package.
TODO: Don't install rom-properties-kio-servicemenus if KF5 is earlier
than 5.85, or install it anyway for forward compatibility?
[kf5] On Ubuntu 16.04, ${SERVICES_INSTALL_DIR} is incorrectly set to
the KDE4 directory. Not usre if it's because kdelibs5 for KDE4 is also
installed... As a workaround, if ${SERVICES_INSTALL_DIR} contains kde4,
change it to "share/kservices5".
Not sure how I didn't notice this before... (probably because
I don't regularly test the 32-bit i386 version, and Ubuntu
didn't ship glibc-2.34 in any LTS releases.)
This resulted in the KF6 libraries being installed in bin/ instead
of lib/. I'm not sure why, or what commit introduced this...
(Possibly a KF6 6.0 RC1 to RC2 change?)
Add a workaround by saving CMAKE_LIBRARY_OUTPUT_DIRECTORY before checking
for Qt6/KF6 and restoring it afterwards.
TODO: Change these macros to functions?
Combining the removal of .gnu_debuglink into the objcopy command had the
effect of losing `strip`'s usual stripping functionality. Add the
`--strip-all` parameter to restore it.
This fixes a regression from commit 356908fe5c.
([cmake] SplitDebugInformation.cmake: Combine the .gnu_debuglink removal into the add-gnu-debuglink command.)
rp-config has been tested and appears to work correctly.
Not able to test other parts yet. I was able to install the KF6 packages,
but my installed copy of Dolphin is still using KF5.
RP_FindQt6andKF6.cmake: Set QT_DEFAULT_MAJOR_VERSION to 6.
Otherwise, Qt6QmlMacros.cmake throws an error: (Qt 6.6.1)
CMake Error at /usr/lib64/cmake/Qt6Qml/Qt6QmlMacros.cmake:2415 (message):
qt_generate_foreign_qml_types() is only available in Qt 6.
Call Stack (most recent call first):
/usr/lib64/cmake/Qt6Qml/Qt6QmlConfig.cmake:132 (include)
/usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
/usr/lib64/cmake/KF6Config/KF6ConfigConfig.cmake:53 (find_dependency)
/usr/share/cmake/Modules/CMakeFindDependencyMacro.cmake:76 (find_package)
/usr/lib64/cmake/KF6KIO/KF6KIOConfig.cmake:41 (find_dependency)
/usr/share/ECM/find-modules/FindKF6.cmake:52 (find_package)
cmake/libs/RP_FindQt6andKF6.cmake:69 (FIND_PACKAGE)
src/kde/kf6/CMakeLists.txt:12 (FIND_QT6_AND_KF6)
Added the same in the Qt4 and Qt5 versions for consistency.
RomPropertiesDialogPlugin, XAttrViewPropertiesDialogPlugin:
- KPropertiesDialogPlugin is now declared in kpropertiesdialogplugin.h.
ProxyForUrl.cpp:
- KProtocolManager::proxyForUrl() was removed in favor of QNetworkProxyFactory.
- FIXME: Not sure if this is correct, especially if the proxy uses https.
- TODO: Verify this!
Link to Qt6::Network for QNetworkProxyFactory.
This broke the GitHub CodeQL and CodeCov.io builds because we're not
installing GTK+ 2.x in those builds, and BUILD_GTK2 isn't a cached
variable; it's a "regular" variable.
The newly-added GTK tests expected BUILD_GTK2 to be unset if GTK2 wasn't
actually found, but this wasn't the case, so it failed to find the
GTK2::gtk target.
[res] Also check for BUILD_GTK4 in addition to BUILD_XFCE and BUILD_GTK3.
Not likely to have caused any problems yet, since no one has a "pure"
GTK4 system yet.
This is now used for the KDE UI frontends, libunixcommon, and the
initial KDE test suite.
This will make it easier to support KDE test suites for all supported
versions of KDE.
Even 12.0 might be too low, but 10.0 is definitely not usable anymore.
CMAKE_SYSTEM_VERSION is set to 10.0 so it will use the latest installed
Windows 10 SDK. This is needed for proper handling of /permissive-
on MSVC 2017 and later.
This makes MSVC a bit more standards-compliant, though it does require
working around some common Win32 idioms. In particular, some const_casts
are needed in order to use constant strings in various structs.
src\win32\RP_XAttrView.cpp(263,31): error C2440: '=': cannot convert from 'const wchar_t [5]' to 'LPWSTR'
src\win32\RP_XAttrView.cpp(263,21): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings)
src\win32\RP_XAttrView.cpp(265,32): error C2440: '=': cannot convert from 'const wchar_t [6]' to 'LPWSTR'
src\win32\RP_XAttrView.cpp(265,21): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings)
src\win32\RP_ShellPropSheetExt.cpp(890,30): error C2440: '=': cannot convert from 'const wchar_t [1]' to 'LPWSTR'
src\win32\RP_ShellPropSheetExt.cpp(890,24): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings)
src\win32\config\AboutTab.cpp(1421,30): error C2440: '=': cannot convert from 'const wchar_t [6]' to 'LPWSTR'
src\win32\config\AboutTab.cpp(1421,19): message : Conversion from string literal loses const qualifier (see /Zc:strictStrings)
CMake 3.1 added CMAKE_<LANG>_STANDARD, which allows CMake to determine
what flags are needed to select a particular language version.
Set it to C17 and C++17. Previously, we were using C11 and C++11,
though gcc11 switched the default C++ version to C++17. The custom
macro handled this by not adding flags for C++, but it still added
the C11 flag, which prevented use of C17.
No code size differences were observed when compiling on gcc-13.2.0
with CMAKE_<LANG>_STANDARD.
mold-2.2.0 adds a bogus .gnu_debuglink section for some reason. It has to
be removed before adding the correct one; otherwise, it fails:
[349/557] Linking CXX executable bin/rpcli
/usr/bin/objcopy: bin/rpcli: debuglink section already exists
On i386, also add -mstackrealign, since i386 was originally defined to
use 4-byte stack alignment. Most programs *should* be updated to use
16-byte stack alignment nowadays, but just in case something isn't,
this will help to prevent alignment exceptions.
Our minimum supported 64-bit Windows is technically NT 5.2, which
includes both Windows Server 2003 and Windows XP x64 Edition,
so we need to disable thread-safe statics on amd64.
This partially reverts commit 648c9d8915.
([cmake] msvc.cmake: Consolidate "/guard:cf"; clean up some other checks.)
FindIntl.cmake sets the singular Intl_LIBRARY variable,
not the plural Intl_LIBRARIES variable.
This didn't cause a problem on Linux, since glibc has libintl built in
and hence doesn't have a separate libintl, but it broke on FreeBSD,
which does *not* have libintl built in.
Windows wasn't affected because CheckGettext.cmake set Intl_LIBRARIES
for the included Windows DLLs. Oopsies.
BUILD_XFCE is an option; BUILD_GTK2 is not.
We should probably get rid of BUILD_GTK2 entirely, since I'm not planning
on adding support for GNOME 2 Nautilus anytime soon.
Also, don't attempt to build rom-properties-glib if none of the GTK UI
frontends are being built.
Fixes CMake issues when building on KDE Neon. (KF6 testing)
C4477: 'function' : format string 'string' requires an argument of type
'type', but variadic argument number has type 'type'
Roughly equivalent to gcc's -Werror=format-security.
Windows 2000 support only partially worked in rp-config. The actual
shell extension component didn't work.
Support for ANSI Windows was mostly just compile-tested, and it was
becoming a burden to support something almost no one will use.
Removed most `#ifdef UNICODE` and `#ifdef _UNICODE` branches in
favor of using the Unicode path exclusively.
Removed oldwincompat, which was an attempt to get things working
properly on Windows 9x and 2000 with the MSVC 2010 runtime.
rom-properties doesn't compile with MSVC 2010 anymore, so this
probably wasn't very useful anyways.
Consolidated tstring macros in tcharx.h.
Removed GUID_fns.c since it was only useful in ANSI builds.
The "/guard:cf" linker check was using the wrong variable, so it didn't
work correctly. Handle it in the compiler flag check instead.
Simplify the checks for "/CETCOMPAT".
Use two underscores in the "/Zc:throwingNew" check for consistency with
the other checks.
Only disable thread-safe statics on i386 for Windows XP compatibility.
We're supporting a minimum of Windows Vista for amd64, and for ARM CPUs,
the minimum is Windows 10.
ARM and ARM64 require MSVC 2019.
ARM64EC requires MSVC 2019.
[cmake] Add toolchain files for ARM and ARM64 on MSVC 2019 and 2022.
(ARM64EC uses the ARM64 toolchain.)
The previous commit broke this.
Also, always use i386 executables regardless of target architecture.
Current Windows builds for non-x86 systems have i386 emulation.
Older non-x86 Windows builds, e.g. PowerPC and Alpha, will probably
not be supported anytime soon due to lack of other essential Windows
functionality.
ARM64EC is always checked before ARM64 (in case both are defined for
some reason) and AMD64 (because MSVC defines _M_AMD64 on ARM64EC builds).
CPUInstructionSetFlags.cmake: Set both CPU_arm64 and CPU_arm64ec.
TODO: Does the Win32 manifest processor architecture change for ARM64EC?
DirInstallPaths.cmake: Set TARGET_CPU_ARCH. This is now used by the
summary at the end of the root CMakeLists.txt.
i18n.c, DelayLoadHelper.c: Add ARM64EC.
CMakeLists.txt: Print ${TARGET_CPU_ARCH}.
v2.2 added JSON plugin metadata to the forwarder plugins. Unfortunately,
KFileMetaData uses a completely different format than other KDE plugins,
which broke metadata extraction.
This was broken in v2.2.
MSVC, in its infinite wisdom, defines _M_AMD64 and _M_ARM64EC when
compiling for ARM64EC (which is "emulation-compatible" ARM64), so
we have to check for _M_ARM64EC and handle it as ARM64, not AMD64.
gcov uses getpid() in gcov_open() if GCOV_LOCKED is defined when
compiling gcc.
I'm not sure why this didn't cause any problems before...
[cmake] options.cmake: Define -DGCOV if building with coverage enabled.
This is used to determine if getpid() should be added to syscall
whitelists, assuming it hasn't been added already for other reasons.
svrplus is Windows only, so instead of gettext, we can use
string tables in resource files.
NOTE: Due to differences between MSVC's rc.exe and binutils's windres,
strings in the string table must be NULL-terminated.
- rc.exe ignores the explicit NULL-termination, but has an option "/n"
that automatically adds NULL terminators to strings.
- windres.exe doesn't have an equivalent to "/n", but it *does* allow
adding '\0' to strings to NULL-terminate them.
Updated msvc.cmake to add "/n" to CMAKE_RC_FLAGS.
NOTE: The '\0's in VS_VERSION_INFO doesn't actually do anything in the
resulting resource section with either rc.exe or windres.exe, so get
rid of them. I think this was mentioned on The Old New Thing before.
Renamed resource.rc to res-en_US.rc and added en_US identifiers.
Compiled executable size doesn't change much.
MSVC 2019, 32-bit release build: (both LTO and no-LTO are identical)
svrplus.exe: 114176 -> 114176 (no change)
text data bss dec hex filename
109644 2048 0 111692 1b44c svrplus.exe [before]
110650 2048 0 112698 1b83a svrplus.exe [after]
+1006 0 0 +1006 +3ee Difference
The gcc-5 workaround stopped working properly due to some recent change.
I can't be bothered to figure out what broke it, and gcc-5 is rather old.
Just don't allow enabling LTO at all.
Removed the GCC_5xx_LTO_ISSUES workarounds in all CMakeLists files.
Reworked the -lgcc workaround to check the compiler version instead
of GCC_5xx_LTO_ISSUES.
This lets us remove "-lgcov", since gcc will automatically add the
coverage library when linking with coverage.
NOTE: Remember to set LD_LIBRARY_PATH when testing code coverage.
Otherwise, the system-wide libromdata.so.2 will be tested, and
that won't have coverage instrumentation.
Some distributions install documentation using distro-specific build
scripts, so add an option to allow our documentation install to be
disabled.
Specify -DINSTALL_DOC=OFF on the CMake command line.
- Split debug symbols doesn't work properly due to an issue with `strip`:
error: symbols referenced by indirect symbol table entries that can't be stripped in: [library]
- Add "arm64" for M1/M2 Macs.
- zstd: "-fdeclspec" is needed for Clang due to use of __declspec() even
on non-MS compilers or OSes. Note that we have to check for both
"Clang" and "AppleClang", since Apple uses its own customized version
of LLVM/clang.
- msvc.cmake: Make sure "Clang" is quoted when STREQUAL is used.
Need to explicitly check for v4. Otherwise, the v3 check will fail,
and it'll just use defaults.
[cmake] FindLibNautilusExtension4.cmake: Add a v4 check file.
RegKey is only used by win32/ (Win32 UI frontend), so it doesn't need to
be in libwin32common, which results in it getting exported by
romdata-2.dll.
NOTE: In theory, we can remove the HINSTANCE parameter from
RegisterComObject() now, since RegKey is always statically-linked into
rom-properties.dll, but we're better off keeping it there.
[doc/abi] RegKey has been removed from the Windows version.
This sometimes causes -D-pthread to be added, resulting in build failures.
librpthreads depends on pthreads on Linux, so removing -pthread from
FindGTKx.cmake shouldn't cause any problems.
No `gdk` target since libgdk was merged into libgtk.
Added libgraphene-1.0, a dependency of libgtk-4.
Removed FindPango.cmake since it's no longer needed.
[gtk4] CMakeLists.txt: Use the new GTK4 targets and get rid of the
now-unnecessary FIND_PACKAGE() calls.
_GTK3_FIND_LIBRARY(): Remove _append_version, since GTK's versioning
has stabilized. Instead, append the version number to the library name.
This prevents mismatched version numbers betwen various GTK versions.
[gtk3] CMakeLists.txt: Use the new GTK3 targets and get rid of the
now-unnecessary FIND_PACKAGE() calls.
Add the following linker options:
- --no-undefined
- --no-allow-shlib-undefined
GTK UI frontends: Link to Pango, GDK, and other libraries directly if
we're using symbols from those libraries.
NOTE: CMake's FindGTK2 seems to do this already, but we'll add the extra
linking ourselves just in case.
This fixes errors similar to the following after adding the
linker options:
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
src/gtk/gtk3/CMakeFiles/rom-properties-gtk3.dir/__/config/CacheTab.cpp.o:
undefined reference to symbol 'gdk_window_set_cursor'
/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/lib64/libgdk-3.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
NOTE: `appstream-util verify` requires the XML file to have the correct
name in the source tree, so we can't simply have it as "metainfo.xml"
and rename on installation.
Other changes:
- rp-config.desktop: Rename on installation to:
com.gerbilsoft.rom-properties.rp-config.desktop
- DIR_INSTALL_MIME -> DIR_INSTALL_XDG_MIME; don't set it on Windows
or Linux.
- [xdg] CMakeLists.txt: Install based on the presence of the
DIR_INSTALL_XDG_* variables instead of the OS.
clang-cl prints a warning, not an error, for these, so it doesn't get
detected by CHECK_CXX_COMPILER_FLAG():
clang-cl : warning : argument unused during compilation: '/Zc:externC' [-Wunused-command-line-argument]
clang-cl : warning : argument unused during compilation: '/Zc:noexceptTypes' [-Wunused-command-line-argument]
This fixes an error that occurs on CMake <3.4:
CMake Warning at cmake/libs/FindThunarX3.cmake:28 (MESSAGE):
ThunarX3_EXTENSIONS_DIR is not set; using defaults.
Call Stack (most recent call first):
src/gtk/gtk3/CMakeLists.txt:49 (FIND_PACKAGE)
CMake Error at src/gtk/gtk3/CMakeLists.txt:213 (INSTALL):
install FILES given no DESTINATION!
