Hi,
trying to build Defold on Linux i am running into following problem:
The recognized C compiler is always clang++ and the compilation process stops with errors as soon as any C lib is compiled with clang++ (obviously C compiled as C++ works only if C code is written carefully with this in mind).
Is there anything i can do to fix this or to control this process better? (i.e. setting CC as an env-var or hardcode somewhere inside build.py, etc).
Thank you
Hi @nkindt !
When I look at our documentation, I realize it doesn’t mention the fact that we don’t use the installed tools, but a certain version of clang which we’ve downloaded from their prepackaged download page.
Current version is 9.0.0 but that isn’t available at the downloads page (I couldn’t find it), but we already use Clang-10.0.1 on the build server, so it should be safe to use that instead. (I’m currently making this update in the repo now so it’ll be easier for others)
The key piece missing in the docs is the fact that you can install sdk packages from a local folder, if the packages are located there.
./local_sdksbuild.py like so:-PACKAGES_LINUX_CLANG="clang-9.0.0"
-PACKAGES_LINUX_TOOLCHAIN="clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04"
+PACKAGES_LINUX_CLANG="clang-10.0.1"
+PACKAGES_LINUX_TOOLCHAIN="clang+llvm-10.0.1-x86_64-linux-gnu-ubuntu-16.04"
./scripts/build.py install_extls tmp/dynamo_home/ext/SDKs and you should find a folder linux/clang-10.0.1 thereNow, try to build the engine again, and the found gcc,cctool should point into the clang-10.0.1 folder.
As I test this myself, I found that it’s not that easy (each compiler upgrade comes with a new set of restrictions I have to work through).
Use the currently used version instead, and everything should work as intended.
https://releases.llvm.org/9.0.0/clang+llvm-9.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
I have updated the readme with this link.
Thanks Mathias for the quick reply! Will try that.
All went well - i ended up with tmp/dynamo_home/bin/x86_64-linux/ as stated in the docs but don’t know how to proceed from here. The Defold binary (everybody is used to) is not present so trying out ./launcher and ./dmengine result in some errors:
./launcher
INFO:TOOLS: Launcher version 1f748d5b0a84e8b5c58bf747e4c48d153ef77a52
FATAL:TOOLS: Failed to load config file './config' (-1)
./dmengine
INFO:DLIB: Log server started on port 35943
INFO:ENGINE: Target listening with name: nk-zen - 127.0.1.1 - Linux
INFO:ENGINE: Engine service started on port 8001
INFO:ENGINE: Defold Engine 1.2.186 (1f748d5)
INFO:ENGINE: Loading data from: .
INFO:ENGINE: Initialised sound device 'default'
INFO:DLIB: SSDP: Started on address 10.0.3.1
INFO:DLIB: SSDP: Started on address 192.168.1.150
INFO:DLIB: SSDP: Done on address 10.0.3.1
INFO:DLIB: SSDP: Done on address 192.168.1.150
The docs don’t mention anything else so might be just me new to Defold and missing some details.
Thanks!
The engine executable is located here:
./tmp/dynamo_home/bin/x86_64-linux/dmengine
but don’t know how to proceed from here.
Well, what do you wish to do?
Ok, that launches a window and waits for connection. I would like to make some changes to the source, recompile and just launch Defold as if i would’ve downloaded it from github. Basically replace current 1.2.186 release with the compiled one and work from there.
You have a few options:
dmengine to the project root and run dmengineI think there’s also an option to launch the editor in “dev mode” which lets you build and run using a local engine.
Alright, thanks!
That’s because you launched it in a directory that doesn’t have the game.project available.
Launch it from your game project folder (make sure you’ve built the content first):
cd my_game_project_folder
./tmp/dynamo_home/bin/x86_64-linux/dmengine
You can edit your editor config and add to the “vmargs” property
,-Ddefold.dev=true
It gives you an extra preference pane called “Dev” in the editor.
Add your custom executable there.
That way you can do “Build and run” directly from the editor.
I am trying the second approach now which seems to be perfect for bash scripts:
Building an android app via bob like this:
java -jar .../tmp/dynamo_home/share/java/bob.jar --archive --platform armv7-android resolve distclean build bundle
and it finishes ok with 100% … done! However i can’t find any logging strings, i added to the source, inside the libdmengine.so that is placed inside armv7-android folder. Recompiling the engine doesn’t show any errors so i am bit confused why there aren’t any strings inside the binary.
I.e. LOGV(“glfw_atexit”) is there as expected:
[0x00021590]> f ~glfw_atexit
0x002c204f 12 str.glfw_atexit
Question is what might be the problem and if i can double check that somehow all went ok with the build. Either way some libdmengine.so is pulled in and it even prints:
Building engine... ...done! during the bob build step with libdmengine.so having the current timestamp.
Some last piece of the puzzle i am missing here. Thanks a bunch!
The logging is deiabled (amongst other things) when you run a release build.
To bundle a debug build add --variant debug
Still the same unfortunately. I can see LOGV strings in binary as before but none of my own which implies that the engine is either not built (although shows success) or somehow a wrong one is pulled in.
I.e. i can fully locate this log string:
if (pthread_self() != g_MainThread)
{
LOGV("Not on main thread, skipping.");
return GL_FALSE;
}
in binary:
[0x00049de0]> f ~Not_on_main
0x002e43f2 30 str.Not_on_main_thread__skipping.
Buy anything i added before to log things won’t show up in the binary no matter what. I.e. added this log string for testing purposes:
static void android_app_free(struct android_app* android_app) {
LOGV("android_app_free() {");
but it’s not included in the binary:
[0x00049de0]> f ~android_app_free
[0x00049de0]>
Anything i could potentially miss or any common build pitfalls or something similar maybe?
Will keep looking, would like to understand the whole process better.
Strange. Could you please share the sequence of command you are running to produce a build?
The engine is built according to the docs (done once and haven’t touched this since):
./scripts/build.py shell
./scripts/build.py install_ext --platform=x86_64-linux --package-path=./packages
./scripts/build.py build_builtins
./scripts/build.py build_engine --platform=x86_64-linux
./scripts/build.py build_bob --skip-tests
The android build is executed like this (in game folder with game.project):
java -jar .../defold/tmp/dynamo_home/share/java/bob.jar --archive --platform armv7-android --variant debug resolve distclean build bundle | grep engine
Building engine... ...done!
Didn’t spot any errors or warning and everything seems to be in order.
That looks like it should work.
Are you using any extensions (dependencies) in your game project?
Dependencies are being used (debug-draw, defold-input, defold-metrics) and one own native extension to call from Lua into Java.
Ok, so then you are building a custom engine, on the cloud server, using officially built engine libraries.
That build doesn’t know about your custom engine build (in particular the libraries you’ve built).
For most engine features/fixes though, I’d recommend testing it in a vanilla project (without native extension dependencies) and then making a pull request.
However, if you intend to continue making a custom engine, you need to build and use a local build server.
Instructions can be found here: GitHub - defold/extender: Native extension build server · GitHub