I'm not 100% sure yet but I think you might have a corrupt copy of miniaudio.h in your amigaOS4 (v4.5) branch?
I've rebuilt glfw against your clib4 and when I try to compile Raylib4.5 it all goes well until I hit miniaudio.h at which point it throws hundreds if not thousands of errors. The file is huge so it's not the easiest to work on but somewhere around line 45000 there appeared to be a part duplicated block of code that just abruptly ends. The errors don't appear to be code errors, more like unterminated #defines and so on, basically like git has not pieced the file together correctly. This is on Github as well as locally so I don't think it's my end.
Search for "/* ScriptProcessorNode." to find the first place it blows up for me.
I have copied the version of the header file from commit c8ae696 (7 months ago) and Raylib build completes without issue. But of course you may well have made valid changes to miniaudio since then as it looks like you've added support for AHI.
I haven't tried Raylib 5 yet as I wan't to do some testing on my project with the existing version before getting into upgrading Raylib. No doubt I will anyway, but one step at a time!
[edit] The copy from the Raylib5 branch looks like a more sane copy that also includes AHI support and if I use that file it also compiles, so maybe it is a correct file in 4.5 branch and the one from 5 is OK? Too late tonight to try to test on X5000 though.
Just tested a fresh cmake configuration and make and everything is working correctly on branch amigaOS (version 4.5) Can you try to redownload everything and compile?
Oh man, I'm not done yet it seems. I've got to rebuild libgl4es now against clib4! Definitely some banging heads against brick walls going on right now.
So, I built glfw, libgl4es and raylib against the now renamed clib2 (now clib4)
I can cross compile from docker a small test program. It sort of worked and sort of didn't. This is the bog standard raylib hello world window. It comes up nicely, I'm off looking at other things for maybe 10 minutes. Come back, click the window to focus it (I had other windows in front) and it just froze the system. I rebooted and just ran it without letting it sit there for 10 minutes and it was fine. I hit escape and the command line program ended but left the window there. Ignore that last bit. I was missing a CloseWindow() statement.
OK, so I figured I'd look at another example that I had which plays some audio. This is code on OS4 I don't have it on my laptop. I modified the Makefile to tell it to use clib4, tried to build it and gcc just tells me I've specified an invalid C runtime.
I guess this is my lack of experience here. I am searching the internet and not just assuming others will give me the answer, but how do I use this new clib4? I have run the installer for clib4 from github.
Edited by MartinW on 2024/4/15 23:47:01 Edited by MartinW on 2024/4/15 23:48:02 Edited by MartinW on 2024/4/15 23:52:13 Edited by MartinW on 2024/4/16 0:11:29
Don't use clib4. Use newlib. glfw/raylib doesn't needs any particular C libary. Most of the code is from OS4 SDK. However if you receive the error you are using an invalid C runtime this means that your adtools gcc is not up to date. That's why in the past i've used clib2 as name so the actual gcc can use the library without any change. You have two solutions now to use clib4. Use docker image with adtools up to date or compile your own version on linux/wsl2/cygwin and use it. But if you want to use just raylib go with newlib.
OK, just to keep this thread up to date with what I said on discord, I'll turn my attention now to your current Amiga Raylib sources and Newlib. I know that's what Hans would prefer anyway. I know that's where I started and couldn't get it to build but maybe things have changed now there has been more work done on it.
Personally I just want whatever works and allows me to focus on my software rather than constantly wrestling with libraries!
So the newlib path is a non starter for someone of my skill level. I just tried to build GLFW against newlib (needed by Raylib) and it throws up a bunch of problems. I hack about a bit, get it part way there, start to use google search only to be pointed to my own posts on here from last year which never got resolved because I moved to CLIB2. I thought we were going round in circles and it looks like I wasn't wrong.
So I have two choices right now. Go back to clib2 where I can cross compile (in docker - I don't use a linux host as such) and native compile as I choose, or stick with clib4 and suffer the pain of the build / copy to NAS / switch machine / copy from NAS / test cycle for even a single line code change.
I'll try the clib2 route to see if I get up and running with that but I thought that was where I started 2 days ago and something didn't work which was fixed by moving to clib4.
Post number 9. The 'stdargs.h' include issue, then the 'MAXPATHLEN' issue, but then by the time I've added 'stdargs.h' and 'amiga_platform.h' I'm left with the following output, for which I have a vague clue what the issue is (newlib not handling library opening in the same way clib2 does and also being missing some things you added to clib2), but I wouldn't know how to solve them.
root@3247e1579380:/opt/code/glfw/build# make
Consolidate compiler generated dependencies of target glfw
[ 1%] Building C object src/CMakeFiles/glfw.dir/os4_init.c.obj
[ 2%] Linking C static library libglfw3.a
[ 23%] Built target glfw
Consolidate compiler generated dependencies of target boing
[ 24%] Linking C executable boing
../src/libglfw3.a(posix_module.c.obj): In function `_glfwPlatformLoadModule':
/opt/code/glfw/src/posix_module.c:41: undefined reference to `dlopen'
../src/libglfw3.a(posix_module.c.obj): In function `_glfwPlatformFreeModule':
/opt/code/glfw/src/posix_module.c:46: undefined reference to `dlclose'
../src/libglfw3.a(posix_module.c.obj): In function `_glfwPlatformGetModuleSymbol':
/opt/code/glfw/src/posix_module.c:51: undefined reference to `dlsym'
../src/libglfw3.a(os4_context.c.obj): In function `destroyContextGL':
/opt/code/glfw/src/os4_context.c:62: undefined reference to `aglDestroyContext'
../src/libglfw3.a(os4_context.c.obj): In function `getProcAddressGL':
/opt/code/glfw/src/os4_context.c:83: undefined reference to `aglGetProcAddress'
../src/libglfw3.a(os4_context.c.obj): In function `swapBuffersGL':
/opt/code/glfw/src/os4_context.c:77: undefined reference to `aglSwapBuffers'
../src/libglfw3.a(os4_context.c.obj): In function `makeContextCurrentGL':
/opt/code/glfw/src/os4_context.c:54: undefined reference to `aglMakeCurrent'
../src/libglfw3.a(os4_context.c.obj): In function `_glfwCreateContextGL':
/opt/code/glfw/src/os4_context.c:145: undefined reference to `aglCreateContext2'
/opt/code/glfw/src/os4_context.c:153: undefined reference to `aglMakeCurrent'
collect2: error: ld returned 1 exit status
make[2]: *** [examples/CMakeFiles/boing.dir/build.make:98: examples/boing] Error 1
make[1]: *** [CMakeFiles/Makefile2:272: examples/CMakeFiles/boing.dir/all] Error 2
make: *** [Makefile:136: all] Error 2
[edit] But I did wonder, that if clib4 is just your clib2 renamed to prevent naming conflicts, then can i just compile raylib using clib4, put a copy of it in the clib2 folder and just tell gcc to use -mcrt=clib2 ? Or are they different enough for that not to work?
OK, so I've now succeeded in building two versions of Raylib v4.5. One against newlib that I can build with on OS4 and one against clib4 which can only be used with a cross compiler environment.
I've run a bunch of tests (from my project) and everything looks OK except 3D. But I can't tell yet whether the issues are my end or my build of Raylib / GLFW / ogles (bear in mind I had to rebuild GLFW for newlib).
So my next step is going to be to look at the examples supplied with Raylib to determine if the 3D issues are my end or not. It's quite likely they are issues in my project as the bulk of my focus has been 2D since that's what I understand more.
Once I'm happy things are stable then I'm going to look at Raylib 5. And then finally spend some time on my project :D
This one use Raylib, which use gl4es, all of which for clib4, and all of which in working shape. All bits (raylib, gl4es and co for clib4) can be grabbed from https://clib4pkg.amigasoft.net/ubuntu/pool/main/ , and if one want update their SDKs manually, just unpack those debs locally and use SDK dir from.
Of course game itself is simple, but point to show that Raylib 4.5.0 works and can be used without needs to re-port it.
By the way, I know this thread is titled Raylib v4.5.0, but I'm pretty sure I built and tested v5.0 and also used that. Ideally, I need to verify that statement which won't be today due to life stuff but that's what my memory says. If I can edit the thread title then I will.
The reason I mention it, and the reason I know it would have been v5.0 is because it uses the SDL2 backend and support for alternative backends didn't come in to Raylib until just after v5.0. So just another option if people prefer. I mean, I guess it's all OpenGL ES at the lowest level behind the scenes anyway.
I got stuck trying to port my little Ninja game (actually from a PyGame tutorial) but that wasn't anything to do with Raylib but instead a function missing from C++ stdlib that the json library that I am using needs. I don't remember off hand which function it was missing and being someone else's json lib I didn't look further into it yet. I'm still porting the game from Python to C++ on my ac so got plenty else to do before I worry about OS4
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
