Who is working on the Godot port?


Show me please, where: https://build.haiku-os.org/buildmaster/master/x86_64/logviewer.html?buildruns/2543/builds/12592.log


Sidenote: You may want to review your dependency on GLEW 1.13 versus GLEW 2.1. :zipper_mouth_face:



This was on my last night’s build using last night’s git pull. This was from two days ago, but still present last night. I did a fresh work directory.


I can only say: works for me, and for the builder bot, so you have to find what’s wrong on your side. For reference: here is the current buildbot log, you can compare it with your output (note: i just updated the port 2 times today,and the bot building it right now, so maybe it isn’t finished yet):



Thanks. I’ll look at it after work tonight.


Btw, you should delete your work folder before relaunching the build.


Thanks. I’ve been doing that.


Build finished, and maybe i’m blind, but according to the output, the bot doesn’t even tried to compile the stream_peer_openssl.cpp file. So you have to find the culprit, i can’t help.

My bad, it did compiled that file. Sorry, Firefox said there is no “ssl” in the log.


I’ll check I out. I tried commenting out the call that failed in the source, but it failed later in the SSL part on something else when I did that.


Looking through some of the Godot forums, I found that it might be possible to link against the native SSL instead of Godot’s. It seems that they only put it in their tree to avoid dependency hell. Haiku is on the same version. Would that be a change in scons or the porter recipe? If I knew which to look in, I’d look into it. I’m thinking some of our problems may be due to rebuilding stuff that already has a haiku recipe. It should be a simple matter of changing where we link from in these cases.


No idea what native lib means in this context.

Usage of libs from separate packages called “system provided” or “shared” or “external”, while the the other way would be the use of the in-tree version, which referred as “in-tree” or “static”.

You may should reread my answers, where i stated it uses the one provided by the openssl package.

But frankly, it isnt a HaikuPorts support forum, if you got a problem with the current recipe/patchset, open a new issue at github.


Native->system provided or shared is what I’d link against. Fair enough on reporting to the git page. Thanks for the help and work so far! On a positive note, I tested a little of Godot’s command line functionality this morning. The latest build in HaikuDepot now has running GDscripts from the command line working. I ran a simple hello world, and it worked!!! This failed on the previous builds.


With the latest 3.0.6-4 recipe, I got it building. Aside from an occasional status report in here to promote community interest, I’ll direct all future bug/development issues on this to github.com/haikuports.


Now it’s time to have Godot working on my Haiku installation! I have an idea for a video game about BeOS / Haiku for so long … it could be the right time with the right tool chain to develop it 100% within Haiku.


We could definitely use some help getting the Godot engine bugs worked out over at HaikuPorts on GitHub. I’m in the same boat. I want this toolchain on Haiku. If you’re willing, we could use more eyes in the code.