slajerek
Compiling v0.64.66 on Debian fails with "unknown type name ‘BYTE’"
Compiling RetroDebugger fails with errors about BYTE and WORD being unknown types. There's also a large number of warnings - I guess at least the "implicit declaration of function X" warning may hint at the root of the problem.
I have tried to compile RetroDebugger as instructed in the README.md, including installing the development libraries and building MTEngineSDL in the same dir where RetroDebugger is.
For a complete log of the output of cmake and make see this: https://pastebin.com/FD1j48pm
- OS: Debian testing
- Version 0.64.66
That's interesting as it compiled for me on Debian just before the release. The unknown BYTE or WORD is chasing me for ages, as on some systems these are defined and compilation fails due to double definition if I add them. The quick fix would be to add in all C files that throw that error something like #define BYTE unsigned char and #define WORD unsigned short and #define DWORD unsigned int at the beginning. I'll have a look at this and check once again on my Debian, maybe something was not committed properly.
I decided to look a little bit deeper into it, so I decided to compile RD in the official Debian docker image so I can have an easily reproducible setup and I can also check different versions easily.
On Bookworm (the current stable) it compiles but I get linker errors (I could not figure out, perhaps some library is not installed?...)
On Trixie (the current testing) I get the errors with the BYTE and stuff.
Bookworm compilation log (had to cut off the middle part because of size limitation): https://pastebin.com/XcbS6XY8
Trixie compilation log: https://pastebin.com/G6r0F2d4
Script used to do the compiling (it does not download the MTEngineSDL and RetroDebugger sources, the directory containing them and the compilation script is simply mounted from the host but it installs the compilers and all the libraries that are mentioned in the docs or cmake complains about): https://pastebin.com/x5G5HEFr
You can get the debian image running and a root prompt within it with
docker run -v /the/dir/with/sources:/mnt -it "debian:bookworm" bash
and then just
cd /mnt
./compile_test_docker.sh
(exiting from the bash running in the docker container stops the container and all changes are reset - so if you start it again you have to install the packages again etc)
OK, so comparing the preprocessor outputs it seems that the BYTE problem is caused by the compiler interpreting
#include "types.h"
in RetroDebugger/src/Emulators/vice/root/util.h differently.
- in bookworm as
RetroDebugger/src/Emulators/vice/arch/types.h(good) - in trixie as
/usr/include/webp/types.h(bad)
libwebp-dev is a new dependency of GTK3.
In RetroDebugger/CMakeLists.txt simply moving the
find_package(PkgConfig REQUIRED)
find_package(SDL2 REQUIRED)
include_directories(${SDL2_INCLUDE_DIRS})
pkg_check_modules(GTK3 REQUIRED gtk+-3.0)
include_directories(${GTK3_INCLUDE_DIRS})
link_directories(${GTK3_LIBRARY_DIRS})
add_definitions(${GTK3_CFLAGS_OTHER})
find_package(ALSA REQUIRED)
block after the
include_directories(
"${CMAKE_CURRENT_SOURCE_DIR}/src/Plugins"
"${CMAKE_CURRENT_SOURCE_DIR}/src/Plugins/CrtMaker"
"${CMAKE_CURRENT_SOURCE_DIR}/src/Plugins/DNDK"
[...]
block fixes the error, though having two include files with the exact same name is a breakage waiting to happen.
Wow, that is interesting finding. I obviously have older GTK3 that's why it compiled for me without a problem. The "types.h" comes from Vice, as you explained I think safer will be to rename this file. I will apply this change. I had similar problem with Atari800 emulator some time ago, that's why some headers there have "a-" prefix.
Thank you for investigating this and also for the Docker script, this will be handy for future builds and possibly CI/CD some day.
I'll apply this change soon and let you know when it's done and ready for testing. Thanks again!
I've fixed this by changing name of the file from Vice types.h to vicetypes.h, the fix will be with next release.