I forgot to do this for the v2.3 release. Oh well.
Notable changes:
- Some "fake" symbols in the MinGW-w64 files are no longer added.
I'm leaving them in the listings for romdata-3 and earlier, though.
- Lots of shared_ptr<> usage.
- More wchar_t* usage on Windows.
NOTE: vtable for RefBase is optimized out in Release builds, but not
Debug builds. As of romdata-3, I'm making sure that I use Release builds
to generate the ABI listings. Older ones may be re-generated later.
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.
Launchpad's Ubuntu 18.04 build (gcc-7) failed:
/tmp/cclqxa26.ltrans0.ltrans.o: In function `LibRpFile::MemFile::~MemFile()':
./build/src/librpbase/tests/./src/librpbase/tests/../../librpfile/MemFile.hpp:45: undefined reference to `vtable for LibRpFile::MemFile'
/tmp/cclqxa26.ltrans0.ltrans.o: In function `RefBase::unref()':
./build/src/librpbase/tests/./src/librpbase/tests/../../librpfile/MemFile.hpp:45: undefined reference to `vtable for LibRpFile::MemFile'
/tmp/cclqxa26.ltrans0.ltrans.o: In function `LibRpBase::Tests::RpPngFormatTest::TearDown()':
./build/src/librpbase/tests/./src/librpbase/tests/../../librpfile/MemFile.hpp:45: undefined reference to `vtable for LibRpFile::MemFile'
/tmp/cclqxa26.ltrans0.ltrans.o: In function `LibRpFile::MemFile::~MemFile()':
./build/src/librpbase/tests/./src/librpbase/tests/../../librpfile/MemFile.hpp:45: undefined reference to `vtable for LibRpFile::MemFile'
collect2: error: ld returned 1 exit status
src/librpbase/tests/CMakeFiles/RpPngFormatTest.dir/build.make:107: recipe for target 'bin/RpPngFormatTest' failed
make[3]: *** [bin/RpPngFormatTest] Error 1
Also export IRpFile and RefBase because MSVC complained:
src\librpfile/MemFile.hpp(23,1): warning C4275: non dll-interface class 'LibRpFile::IRpFile' used as base for dll-interface class 'LibRpFile::MemFile'
src\librpfile\IRpFile.hpp(33,1): warning C4275: non dll-interface class 'RefBase' used as base for dll-interface class 'LibRpFile::IRpFile'
src\librpfile/MemFile.hpp(150,15): warning C4251: 'LibRpFile::MemFile::m_filename': class 'std::basic_string<char,std::char_traits<char>,std::allocator<char>>' needs to have dll-interface to be used by clients of class 'LibRpFile::MemFile'
I'm not sure about the std::string issue, though...
This shouldn't affect the ABI significantly, so I'm not going to bump
the SOVERSION.
(cherry picked from commit 7be8249624)
AppVeyor Ubuntu 18.04 was failing to build the XFCE (GTK2) UI frontend
because it couldn't find the VectorFile vtable:
src/gtk/xfce/CMakeFiles/rom-properties-xfce.dir/__/DragImage.cpp.o:
In function `drag_image_drag_data_get(_DragImage*, _GdkDragContext*, _GtkSelectionData*, unsigned int, unsigned int, void*)':
src/librpfile/VectorFile.hpp:29: undefined reference to `vtable for LibRpFile::VectorFile'
I wouldn't have noticed this without adding --no-undefined because there
aren't any automated UI tests right now. (Well, maybe I would have noticed
it on my Xubuntu 16.04 VM, but maybe not...)
Interestingly, the MSVC builds export *all* of VectorFile's functions,
whereas the gcc builds (even on Windows) don't export the inlined ones.
This probably isn't an issue, since VectorFile function access usually
goes through the vtable, and for cases where it doesn't, the inlined
functions will be inlined.
This will make it easier to test e.g. Windows executables without having
to scroll through pages of DLL imports/exports.
[librpbase] TextOut: Use a flags parameter instead of bool so we can have
multiple flags.
[doc/abi] Updated ABIs to reflect the use of `unsigned int` for flags.
Interestingly, the Windows gcc ABIs already used this instead of `bool`...
I probably added it in manually before, which didn't match the
`sort` order.
Gentoo Linux: Also add the AesNettle version functions. These were listed
in the Ubuntu ABIs, but not the Gentoo one.
Split from the GTK and KDE CacheCleaner objects.
The new function also supports using statx() if available.
A basic version is now implemented on Windows. It only supports
distinguishing between files and directories.
This function is exported, since it's used by the UI frontends.
The IAesCipher subclasses no longer export their constructors.
AesCipherFactory::create(Implementation) is exported.
AesNettle exports various functions so the UI frontends don't have to
link to nettle directly.
RpPng exports various functions so the UI frontends don't have to link
to zlib or libpng directly.
FileSystem::access() is now exported.
- Also FileSystem::waccess() on Windows.
Windows-specific changes:
- InitPropVariantFromString_noShlwapi() is now exported because it's
no longer an inline function.
- InitPropVariant* functions are now WINAPI for compatibility with the
original Windows functions.
Main changes:
- `nm` prints consolidated versions of certain templates, e.g.
std::ostream& instead of std::basic_ostream<blah>, so I'll be using
`nm` on the import libraries instead of `dumpbin` on the DLLs for
the MinGW-w64 versions.
- Added rp_vswprintf() and rp_vswprintf_p().
- Functions that previously took `const SIZE&` now take `SIZE`.
- Functions moved to LibWin32UI are no longer exported from libromdata.
- RegisterComObject() now takes an HINSTANCE parameter so it can get the
correct DLL filename, since libromdata doesn't export any COM objects
itself.
It seems I incorrectly had pfnIsThemeActive and RP_ulTotalRefCount
marked as T (text) when they should have been marked as B (bss).
Also, the difference with the MSVC files is how I obtained the
undecorated names. Initially, I took the `dumpbin /EXPORTS` output and
only kept the undecorated names from there, which was a bit error-prone
due to formatting. For the new one, I took the decorated names, which
was easier to get, then ran those through `undname`.
The amd64 file was missing __ptr64 in most of the functions for some
reason. (Did I get the versions confused before?)
The i386 file was missing const qualifiers for some of the functions.
I guess the method I used before wasn't very reliable.
Also, I accidentally duplicated imageTypeCount() in both of them due to
manual editing instead of regenerating the files.
In order to thumbnail Wii U Packages, and probably some other packages
I'd like to add later on, we have to thumbnail a directory. This isn't
doable with IRpFile, so as a workaround, use a filename.
This overload will create an RpFile and pass it to the usual create()
function if it's a file. For directories, it currently does nothing,
but it will eventually do something.
doc/abi/: Add this function to the ABI lists.
The program version, git version, and git description are now accessed
using the getProgramInfoString() function. This function also provides
some other strings, including the copyright string, which is now used
by the UI frontend "About" tabs.
getProgramInfoStringCount() returns the number of strings available in
the library, which corresponds to ProgramInfoStringID::Max, currently 6.
Instead, there were two LibRpBase::RomFields::getFromListDataMulti().
Not sure how that happened.
Removed stray ')' from AboutTabText variable entries.
These exports were taken with MSVC 2019, not MSVC 2017, though they
should be the same as 2017 and 2015 due to MSVC's new commitment to
C++ binary compatibility starting with 2015.
Exports were dumped using DUMPBIN /EXPORTS and demangled using c++filt,
then prefixed with the symbol types from the Linux build.
TODO: The Linux exports files are missing some symbols.
Five systems are included:
- Gentoo (amd64) with gcc12 and glibc-2.35 (my main development system)
- Ubuntu 16.04 (i386) with gcc5 and glibc-2.23
- Ubuntu 16.04 (amd64) with gcc5 and glibc-2.23
- Windows (i386) with MSVC 2017
- Windows (amd64) with MSVC 2017
For the Linux builds with gcc, symbols are demangled and sorted using
`sort -u`. (See the dump-exports.sh script.)
For the Windows builds, symbols are demangled using `DUMBPIN /EXPORTS`.
Windows DLLs always have a sorted symbol table, though they're sorted
according to the mangled symbol, which starts with the function or
variable name, and is followed by classes/namespaces. Hence, the sorting
order may seem a bit unusual.
C symbols on Windows are also demangled to make comparisons easier.
Windows usually prefixes C symbols with '_' on 32-bit, and no prefix
on 64-bit.
NOTE: The gcc5 builds have five extra exported symbols that are hidden
by later versions of glibc: __bss_start, _end, _edata, _fini, _init.
_init and _fini were hidden in glibc-2.28; not sure about the others.
