So there was a bit of back and forth between my OGA and my desktop
(https://github.com/pmprog/allegro5/commits/master)
I've managed to "fix" my code errors, but I'm having trouble building.
odroid@goadvance:~/allegro5/build$ make -j2
[ 6%] Built target copy_demo_data
[ 12%] Built target copy_skater_data
[ 13%] Linking C shared library lib/liballegro.so
[ 28%] Built target copy_example_data
[ 28%] Built target docs
/usr/bin/ld: CMakeFiles/allegro.dir/src/odroidgoadv/oga_system.c.o: in function `_al_register_system_interfaces':
/home/odroid/allegro5/src/odroidgoadv/oga_system.c:170: multiple definition of `_al_register_system_interfaces'; CMakeFiles/allegro.dir/src/unix/udrvlist.c.o:/home/odroid/allegro5/src/unix/udrvlist.c:46: first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/allegro.dir/build.make:1076: lib/liballegro.so.5.2.7] Error 1
make[1]: *** [CMakeFiles/Makefile2:694: CMakeFiles/allegro.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
odroid@goadvance:~/allegro5/build$
I don't really know why I'm getting duplicate
_al_register_system_interfaces, as far as I can tell, I'm copying the
GP32Wiz one closely enough.
Any ideas?
Cheers
Friday, June 26, 2020, 8:47:51 PM, you wrote:
MW> Hello SiegeLord,
MW> Thanks for the reply.
MW> I've made an incomplete commit here:
MW> https://github.com/pmprog/allegro5/commit/b0908beb1f5ecb9cbb5c40ed7678d7758c5c859b
MW> I don't suppose you wouldn't mind just giving it a quick glance over
MW> to make sure I'm heading in the right direction. I ended up looking
MW> at a mix of the SDL and Wiz configuration, because aside from the
MW> toolchain, the Wiz is more akin to the OGA.
MW> So I think I'm on the right lines, but didn't want to waste all too
MW> much time for you to turn around and say "Nar, you didn't wanna do
MW> that" to quote Harry Enfield.
MW> As I mentioned, I don't really understand Linux drivers, or the
MW> display systems, however, the libgo2 library I linked does wrap that.
MW> I was just going to use that, but if it turns out that we could share
MW> some codebase, then yes, that would be better. Maybe the libgo2
MW> KMS/DRM wrapper might help you with some of your KMS/DRM code?
MW> I guess one of my other problems, is I can't even test what I have
MW> written, because of the lack of the video driver aspect. I hope the
MW> joystick code is okay. I checked how to use libgo2 in a test project,
MW> and use the same style as the wiz for threaded state comparison.
MW> Regards,
MW> Mark
MW> Thursday, June 25, 2020, 8:00:57 AM, you wrote:
S>> Hi Mark,
S>> Let me answer your questions in-line.
S>> On 6/24/20 5:40 AM, Mark Watkin wrote:
Hello all,
I put a thread up on allegro.cc, but it's locked, so I thought I'd
reask here.
I want to get an Allegro build running on the Odroid Go Advance.
(https://www.hardkernel.com/shop/odroid-go-advance-black-edition-clear-white/)
It's a Linux machine, but the reference image doesn't have X11; and
the display uses KMS/DRM. I don't really understand all the
different driver components in Linux, but OtherCrashOverride has a
library for access the Go Advance hardware, and his "RetroRun2"
shows usage of EGL and GLES2
https://github.com/OtherCrashOverride/libgo2
https://github.com/OtherCrashOverride/retrorun-go2/blob/master/src/video.cpp
I created a "Toolchain-odroidgoadv.cmake" in the cmake directory,
but, building on the OGA just uses the regular linux toolchain (the
compilation only fails due to missing GL header files).
So is creating a new Toolchain file the right way to add support to
the device?
S>> Generally you only need a toolchain file if you need to use a custom
S>> C/C++ compiler. Honestly, I think we use it too often. I'd use SDL
S>> driver as a good, minimal, example, which only requires setting
S>> ALLEGRO_SDL to `true` via `cmake -DALLEGRO_SDL=1` which then triggers
S>> everything.
I also then created a folder /src/odroidgoadv, and dropped in there
a file called ogajoy.c, which contains my inital joystick code
(based on the /src/sdl/sdl_joystick.c file), and I'll create
"ogadisplay.c" for the display and "ogasystem.c" for configuring the
system VTable, and just copy the majority from the linux base, but redirect
joystick and graphics to my new functions.
Again, is this the right way of doing it? And if so, what causes the
selection of the ALLEGRO_SYSTEM_INTERFACE?
S>> The way the system driver registration works is that in system.c:
S>> https://github.com/liballeg/allegro5/blob/326fb49a6b979e43aa434f42925093d9b6e9b83d/src/system.c#L252
S>> we call _al_register_system_interfaces. This function is defined on each
S>> platform:
S>> $ git grep 'void _al_register_system_interfaces' src
S>> src/android/android_system.c:void _al_register_system_interfaces(void)
S>> src/gp2xwiz/wiz_system.c:void _al_register_system_interfaces(void)
S>> src/iphone/iphone_system.c:void _al_register_system_interfaces(void)
S>> src/macosx/system.m:void _al_register_system_interfaces()
S>> src/sdl/sdl_system.c:void _al_register_system_interfaces(void)
S>> src/unix/udrvlist.c:void _al_register_system_interfaces(void)
S>> src/win/wsystem.c:void _al_register_system_interfaces()
S>> The CMakeLists.txt makes sure that only one of those files is actually
S>> included in the library. For example, for SDL we have:
S>> if(ALLEGRO_SDL)
S>> list(APPEND LIBRARY_SOURCES ${ALLEGRO_SRC_SDL_FILES})
S>> list(APPEND PLATFORM_LIBS ${SDL2_LIBRARY} m)
S>> include_directories(${SDL2_INCLUDE_DIR})
S>> endif(ALLEGRO_SDL)
S>> Where ALLEGRO_SRC_SDL_FILES is defined in cmake/FileList.cmake.
S>> So, in summary, to create a new driver you at the minimum need to do the
S>> following:
S>> 1. Create a file which defines `_al_register_system_interfaces`.
S>> 2. In cmake/FileList.cmake a variable that mentiones that file.
S>> 3. In CMakeLists.txt add an option to select your driver. Make sure to
S>> turn off other platforms as necessary if your option is selected.
S>> 4. Add the variable from step (2) to the list of platform sources.
S>> Now, it's interesting that you mention KMS and DRM. I'm actually trying
S>> to add a RPI4 KMS + DRM driver, so perhaps there's something that can be
S>> shared in these two backends. My code is sadly not yet ready however.
S>> -SL