Seems like a lot changed since I git cloned last night. I’m still learning git. What’s the best way for me to proceed getting my system synched with current development?
Probably (git newcomer here too):
in the haikuports root directory. Since you probably wont have changes done on the code / files.
Thanks. Did a git pull. Godot builds into linking phase and throws a modal alert:
Haikuporter could not unmount ‘system’ volume in chroot. What would you like to do? [Force unmount] [Give up]
Update: clicked force unmount. Build fails.
/sources/godot-3.0.6-stable/modules/openssl/stream_peer_openssl.cpp:624: undefined reference to ‘X509_free’
This seems to have to do with libcrypto.so. I have libcrypto.so.1.0.0 on my system. Does Godot expect a newer libcrypto.so?
Is ld being invoked -as-needed?
I think I’m going to dig in to scons abit. I’m like a fish out of water.
Strange, it built fine for me locally, but neither you nor the buildbots was able to get it built.
You have the recipe set with builting openssl as no.
Grabbed your merged recipe with a pull, setting that to yes, and it compiled ok (now packaging) from scratch, without problems.
You might have openssl compiled and changed the recipe, do other changes, or yadayada.
Edit: it fails with:
no renderer found! ERROR: initialize: Error initializing GLAD At: drivers/gles3/rasterizer_gles3.cpp:147. ERROR: initialize: Your system's graphic drivers seem not to support OpenGL 3.3 / OpenGL ES 3.0, sorry :( Try a drivers update, buy a new GPU or try software rendering on Linux; Godot will now crash with a segmentation fault. At: drivers/gles3/rasterizer_gles3.cpp:157. ERROR: Your system's graphic drivers seem not to support OpenGL 3.3 / OpenGL ES 3.0, sorry :( Godot Engine will self-destruct as soon as you acknowledge this error message. OpenGL ES 3.0 Renderer: Kill Thread
That’s not a good solution, i pushed a bugfix patch right now to use the sys provided openssl.
ERROR: Your system’s graphic drivers seem not to support OpenGL 3.3 / OpenGL ES 3.0, sorry
Start with MESA_GL_VERSION_OVERRIDE=“4.1FC”
Best to use within your terminal environment (Haiku R1B1 x86_64 or higher):
env MESA_GLSL_VERSION_OVERRIDE=450 env MESA_GL_VERSION_OVERRIDE=4.5COMPAT /boot/system/apps/Godot/Godot
GalliumContext: CreateScreen: Using llvmpipe (LLVM 5.0, 128 bits) driver.
OpenGL ES 3.0 Renderer: Gallium 0.4 on llvmpipe (LLVM 5.0, 128 bits)
Road closed, vmware VM has no GL Renderer, not even for GLTeapot, even if I mark the display device as accelerated so… Cannot do more in this topic
GLTeapot is broken even on real iron currently, pls do not extrapolate from this info.
Are you using ESXi? I have it working fine in VMware Workstation.
I was also trying other glcommands. And GLTeapot works on the real pcs i worked with (), until i add enough teapots.
This error is “No GL renderer found!”, yep mesa is installed and everything else seems to work normally.
I was using the windows VMware (workstation) player version, this is a desktop pc.
Do you have swrast or swpipe installed?
Is it possible that there are issues between Godot and the GNU toolchain? For instance, Godot won’t build on OpenBSD without using llvm.
The point my building of Godot is failing is in compiling ssl. Since godot uses ssl 1.0.x, and that’s the default branch used in Haiku, could we avoid a potential headache by having godot use Haiku’s build of ssl and not build it again for godot? How does that work?
Already solved in the current recipe. Check that out, and report back if it is still failing for you.
It should be even in the Depot already: https://build.haiku-os.org/buildmaster/master/x86_64/?buildrunDir=2543&viewMode=expanded
Interestingly it isn’t, hovewer it built without error for x86_64.
Build still fails on x86, but i think i found the reason, will check today night.
For the tl;Dr, did you link against Haiku’s ssl or get godots version building. I’ll rebuild tonight. I built last night against what was in HaikuPorts git around 7:30MST
According to the guidelines, every ports in HaikuPorts should use the system provided libs instead on the in-tree version, if there is no good reason against it.
Make sure you use the current patchset, not just the recipe.
True, but when I’m building Godot from ports, it’s accessing the SSL in it’s own tree. Will get back at it tonight.