iOS Question Hosted Builder reports Error: ** BUILD INTERRUPTED ** on a large B4i project

[b4x-de]

Hi,

I have a large B4i project that is built with the hosted builder. The build is interrupted near the end, but I cannot find a real compiler or linker error in the log. The final error is only:

Error: ** BUILD INTERRUPTED **

The generated Xcode build is very large. The log contains 508 CompileC steps before the build stops. The generated project contains hundreds of Objective-C .m files.

My current assumption is that this is not a B4X syntax issue and not a normal Xcode compiler/linker error, but possibly a timeout or resource limit on the hosted builder because the project is very large.

One additional observation: it seems to work sometimes. However, after a successful build, the next build often fails again with BUILD INTERRUPTED. I then have to switch the hosted builder from Primary to Secondary, or the other way around, before another successful build is possible. After that, the same pattern can repeat.

Questions:

1. Is Error: ** BUILD INTERRUPTED ** expected when the hosted builder times out or cancels a long build?
2. Are there known limits for hosted builder build time or project size?
3. Is there a way to get a more specific reason for the interruption?
4. Could the need to switch between Primary and Secondary hosted builder indicate a cache / cleanup / stale state issue on the builder side?

I can provide the full build log if needed. The log has about 11,600 lines and the file size is about 3.9 MB.

Thanks in advance for any help or hints,
Thomas

 

[Erel]

Please send me the logs to [email protected]

 

[Erel]

It does look like a timeout. How long does it take it to return the error?
What is the project size (in the compilation window)?

 

[b4x-de]

It does look like a timeout. How long does it take it to return the error?
What is the project size (in the compilation window)?

In Release mode:
The project size is 23.33 MB
If remote compilation in Release mode is successful the step takes 280.76s

In Debug mode:
The project size is 8.71 MB
If remote compilation in Debug mode is successful the step takes 277.49s

The error isn't occurring right now. I was able to compile successfully in both release and debug modes.

 

[b4x-de]

I'm now experiencing the same issue with a second app. The project size in release mode is 32.46 MB. After remote compilation starts, Windows reports after 270 seconds that the local B4i application is no longer responding, and after about 360-390 seconds (~ 6 minutes), the following error appears: ** BUILD INTERRUPTED **.

 

[b4x-de]

I also tried it on the Local Builder tonight. The error occurs there as well. However, it’s worth noting that in the Local Builder’s output, the error is displayed the moment Windows detects that the local B4i application has stopped responding. That’s about 240–250 seconds (~ 4 minutes). I raised the HungUpTimeout to 9 minutes in Windows Registry but with no success.

 

[Erel]

Have you tried to change Tools - IDE Settings - Configure process timeout?

Depending on how your project is built, you might benefit from compiling parts of it as libraries.

 

[b4x-de]

Yes, it was already at 900 seconds (15 minutes). I don't think it is a problem at the B4i IDE, but a timeout at the server side.

 

[Erel]

I just verified it in the code, there is a 4 minutes timeout in the builder code. I can make it configurable with the local builder.

 

[Erel]

I'll send you a private message with a link to the updated builder. You can set the timeout by adding to config.txt on the Mac:
Timeout=900

The timeout is printed in the server logs.

 

[b4x-de]

Thank you, I can compile the app on local builder with the new version and the timeout set in config.txt.

Btw: All other parameters in the "config.txt" file start with a lowercase letter, but the new "Timeout" parameter does not. If you like, you can also change it to lowercase to match the current convention.

Timeout=900

Depending on how your project is built, you might benefit from compiling parts of it as libraries.

Yes, the app is built from components that were developed and tested separately, corresponding to the underlying architectural layers. I will follow your advice and compile the previously platform-independently developed components (*.b4xlibs) into platform-specific libraries to reduce the now critical compilation times for B4i.

 

[Erel]

Btw: All other parameters in the "config.txt" file start with a lowercase letter, but the new "Timeout" parameter does not. If you like, you can also change it to lowercase to match the current convention.

The keys are indeed not consistent. There are also CertBotExe, AppPath and BuilderIp, so will keep it like this.

 

[b4x-de]

I'll send you a private message with a link to the updated builder.

Since the update to V10.02 of Local Builder that I received via private message, the problem with the iRSA library has returned, even though I haven't made any changes to the libraries. (I just replaced the JAR file with the new version.)

The problem had already been solved here: https://www.b4x.com/android/forum/t...e-since-the-first-release.170140/post-1041765

Update: This error only occurs when the project is compiled into a library (Alt + 5). Compiling and running the project directly works without any issues.

What did I do wrong, or what did I configure incorrectly?

This is the Local Builder error message:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only arm64 -D -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS26.1.sdk -L/Users/user1/Build/B4iBuildServer_v10-00/UploadedProjects/<user id>/build/Release-iphoneos -filelist /Users/user1/Build/B4iBuildServer_v10-00/UploadedProjects/<user id>/build/B4iProject.build/Release-iphoneos/b4i-example_b4i.build/Objects-normal/arm64/b4i-example_b4i.LinkFileList -framework Foundation -framework CoreGraphics -framework UIKit -framework iArchiver -framework iCore -framework iDateUtils -framework iEncryption -framework iRandomAccessFile -liRSA -framework iStringUtils -framework iXmlBuilder -framework iXmlSax -framework AVFoundation -dependency_info /Users/user1/Build/B4iBuildServer_v10-00/UploadedProjects/<user id>/build/B4iProject.build/Release-iphoneos/b4i-example_b4i.build/Objects-normal/arm64/b4i-example_b4i_libtool_dependency_info.dat -o /Users/user1/Build/B4iBuildServer_v10-00/UploadedProjects/<user id>/build/Release-iphoneos/b4i-example_b4i.framework/b4i-example_b4i
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -liRSA
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -liRSA is not an object file (not allowed in a library)
Command Libtool failed with a nonzero exit code

Error: ** BUILD FAILED **

 

[Erel]

Probably related to iRSA being an old format library.

 

[b4x-de]

After looking at this more carefully, I think the issue is a combination of the old iRSA library format and the way B4i builds native libraries.

The failing command is the native-library build step. Xcode / libtool is called with something like:

libtool ... -L/.../UploadedProjects/<user id>/build/Release-iphoneos ... -liRSA ...

The important part is that -liRSA expects to find libiRSA.a in one of the library search paths. However, in this native-library build, the only relevant -L path points to the generated build/Release-iphoneos folder. The original libiRSA.a is still located in the Build Server Libs folder, so libtool cannot find it:

can't locate file for: -liRSA

A normal app build can still work because it uses a different build/linking flow and can resolve the library from the Build Server Libs folder. The native-library build is different: it creates a static framework/library and calls libtool directly. In that step, the old .a library is not automatically copied or searched.


Because the normal app build works, but Compile To Library fails because libtool cannot locate libiRSA.a, I think this might be a bug or at least an inconsistency in the Compile To Library build process when legacy .a libraries are involved. Therefore I reported it here with more details:

Compile To Library fails with legacy iRSA library, while normal app build works on B4i 10.00

Hi, first of all: thank you for the continuous work on B4i and the Build Server. The move to the newer build infrastructure and xcframework-based libraries is a big step forward. I am reporting this because I think I found a small inconsistency in the native-library build flow that might be...

www.b4x.com