SDK 3.10 no longer builds

REPRODUCIBILITY: 100%
OS VERSION: 22/Jammy, SFOS 4.5.0.19
HARDWARE: Thinkpad w541, xperia 10iii, volla22
UI LANGUAGE: en_US
REGRESSION: yup

DESCRIPTION:

sdk build no longer builds what it did with the previous version.

PRECONDITIONS:

an sdk project which previously built successfully.

STEPS TO REPRODUCE:

  1. open a project which was previously worked on with an older version of the sdk
  2. clean
  3. run qmake
  4. build (rpm → device)

EXPECTED RESULT:

.o files, a binary, an rpm after a possibly long time. Previous SDK, this project required up to 10 minutes depending on options. Yesterdays last build did create a large file:

 70M	/home/mwa/src/sailfish/build-harbour-babbage-SailfishOS_4_4_0_58_aarch64_in_Sailfish_SDK_Build_Engine-Debug/calculator.o

but it built, repeatedly, fine.

ACTUAL RESULT:

Um, looks like the linker is fucked? I’m not sure. After 40 minutes, I restarted everything (reboot) and did clean etc. Still waiting.

MODIFICATIONS:

ADDITIONAL INFORMATION:

Inside the build engine, top shows:

 6840 mersdk    20   0  907020 846556    228 D  16.4  82.8   5:43.36 ld-linux.so.2   

Is it possible it’s running out of ram?

Trying to build:

I just tried building your app on sdk 3.10 and it built just fine. There is a small difference in my setup though: I’m using docker build engine.

I did notice that the compiler indeed takes quite a lot of memory, it was at least 1.3 GB. So you might want to try increasing the amount of RAM available for the build engine, using sfdk engine set vm.memory-size=<value>. You can use sfdk engine show to see the current value, I suggest you double that number.

Ok, given that docker is considerably more performant, maybe I should just re-install with docker?

I did a manual adjustment of the RAM in virtualbox to 2048 which resulted in:


of 116916224 bytes
{standard input}: Assembler messages:
{standard input}:7049142: Fatal error: can't close calculator.o: memory exhausted
make: *** [Makefile:446: calculator.o] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.rQiNnk (%build)

Interesting is that with 1024 mb since no procs could fork, the sdk just sat waiting while nothing was happening.

Thanks for looking!

Now test the new programmable calculator :slight_smile: Sneaky!

If you are familiar with docker, I would recommend it. It has it’s own peculiarities, so if you are not familiar with it, it’s possible that you just end up with a different set of problems.

Looks like even 2048 was not enough, maybe with 4096 then?

Yeah, that is indeed weird. Usually the compiler just dies when it runs out of memory, and the SDK detects that and prints an error message with a hint to increase RAM.

Tested it, it’s nice :slight_smile:

4096 did the trick.

I’ve been avoiding docker but I know my way around lxc (and linux vserver) … hmmm. the c++ build time improvement could be meaningful.

Hmmm. I think I’ll try it. If it saves me a third of the time compiling it’ll be worth it for anything where more than 2 or 3 files change at a time. or mega headers like exprtk are involved.

Yeah!

Hi @poetaster - are you still using docker?, if so, do you recommend using it instead?

I’ve never used docker :slight_smile: Don’t like it :wink: As has been pointed it, it’s faster to compile for c++. I’m preferring to put the extra energy I have in github builds and chum.