KmyMoney Mac Os Build (ARM)

[Thomas Baumgart]

Hi Marco,

thanks for the lengthy report. I did not have the time to go through all
of it but will certainly do once time permits.

Are you aware of https://discuss.kde.org/t/successful-build-of-kmymoney-5-2-qt6-master-on-macos-arm64/45898
or is KTL even you?

Thomas

On Dienstag, 14. April 2026 23:26:31 CEST francem--- via KMyMoney-devel wrote:

> 
> Hi,
> 
> let me start saying I'm not an experienced macOS developer,
> but I used to be a Java developer, and I've been a happy KMyMoney user
> on Mac for several years.
> 
> Being aware of KmyMoney build issue, I tried
> to see whether, with AI/ChatGPT support, I could make a local build on a
> fresh macOS environment.
> I created a VM on UTM on an Apple Silicon Mac,
> used Craft as the build tool, and with ChatGPT's support managed to
> produce a working KMyMoney app and DMG package.
> 
> Beign able to complete
> the build I tried the same approach to test locally the CI/CD pipeline
> and found some fixes to be applied to let it work.
> I'm not saying this
> is perfect or the best but, with the following actions the pipeline
> completed the build. 
> Don't know if anyone in the Dev team could check
> and verify but, please find hereafter a ChatGPT actions report:
> 
> This
> document summarizes the changes and follow-up recommendations that
> should be shared with the developers after reproducing the macOS ARM64
> CI/CD build locally. It focuses on the concrete fixes that unblock the
> pipeline, the exact files involved, and why each change is necessary for
> automated builds. 
> 
> The local reproduction showed a sequence of failures
> and recoveries: 
> 
> 	* 
> 
> libs/zlib failed because the blueprint still
> requested zlib-1.3.1.tar.xz, which now returns 404.  
> 	* 
> 
> After
> updating zlib to 1.3.2, the dependency chain progressed, but
> libs/gwenhywfar required a macOS ARM compile workaround for arm_acle.h. 
> 
> 	* 
> 
> After gwenhywfar succeeded, the main project configure failed
> because the macOS bundle install rule for the kmymoney executable was
> incomplete.  
> 	* 
> 
> With that corrected, the full build completed
> successfully and produced macos-arm-clang/Applications/KDE/kmymoney.app.
> 
> 
> -------------------------
> 
> FILE:
> craft-clone/blueprints/libs/zlib/zlib.py 
> 
> RELEVANT AREA: setTargets()
> and the version-specific patch/digest blocks around the 1.3.1 / 1.3.2
> entries. 
> 
> OBSERVED LOCAL BEHAVIOUR: the pipeline tried to download
> https://www.zlib.net/zlib-1.3.1.tar.xz and received HTTP 404. After
> changing the blueprint to 1.3.2, the tarball downloaded successfully and
> the archive was valid. 
> 
> The blueprint should use 1.3.2 as the default
> target instead of 1.3.1. The relevant changes are: 
> 
> 	* 
> 
> Update the
> target list so the supported release set includes 1.3.2 instead of
> 1.3.1.  
> 	* 
> 
> Update the targetDigests entry to match the 1.3.2 tarball.
> 
> 	* 
> 
> Set defaultTarget = "1.3.2".  
> 	* 
> 
> Remove the
> zlib-1.3.1-20240818.diff patch from the 1.3.2 patch list.   
> 
> The
> pipeline failed at the very first dependency fetch because the version
> hardcoded in the blueprint no longer exists upstream. That makes the CI
> job deterministic but broken: every run repeats the same 404 until the
> blueprint is updated. 
> 
> The local reproduction proved that
> zlib-1.3.2.tar.xz exists, downloads cleanly, and passes archive
> validation. That means the change is not speculative; it is a direct fix
> for the CI artifact source. 
> 
> This is the highest-priority upstream
> change. It is a pipeline blocker and should be merged first because
> every later build stage depends on libs/zlib.
> 
> 
> -------------------------
> 
> FILE: kmymoney/CMakeLists.txt 
> 
> RELEVANT
> AREA: the install(TARGETS kmymoney ...) block around the line reported
> by CMake, approximately line 204 in the local checkout. 
> 
> OBSERVED LOCAL
> BEHAVIOUR: CMake stopped with:  
> 
> install TARGETS given no BUNDLE
> DESTINATION for MACOSX_BUNDLE executable target "kmymoney" 
> 
> The build
> then aborted during the configure stage, before any compile or package
> install step could complete. 
> 
> Add a macOS bundle destination to the
> install rule for the kmymoney executable. The missing clause is:
> 
> 
> BUNDLE DESTINATION ${KDE_INSTALL_BUNDLEDIR}
> 
> The install(TARGETS
> kmymoney ...) block should include a bundle destination alongside the
> runtime/library destinations already used by the project. 
> 
> On macOS,
> kmymoney is built as a MACOSX_BUNDLE application. CMake requires an
> explicit bundle destination when installing a bundle target. Without it,
> configure fails before the build can continue. This is not a runtime
> issue; it is a packaging/install rule issue that stops the CI job during
> the configure phase. 
> 
> The local build completed successfully after
> adding the bundle destination, and the final artifact was installed as:
> 
> 
> macos-arm-clang/Applications/KDE/kmymoney.app 
> 
> That confirms the
> destination is correct for the KDE macOS layout. 
> 
> This is a
> source-level fix in the project CMake files, not a Craft workaround. It
> should be treated as a real CI/CD compatibility fix for macOS.
> 
> 
> -------------------------
> 
> FILE LOCATION: no upstream source file was
> identified during the local session; this was handled as a
> build-environment workaround. 
> 
> OBSERVED LOCAL BEHAVIOUR:
> libs/gwenhywfar failed during the Qt-related compile step because Qt 6
> headers on macOS ARM64 reached qyieldcpu.h, where __yield() was not
> declared. The error message pointed to: 
> 
> error: implicitly declaring
> library function '__yield' with type 'void ()' 
> 
> Adding -include
> arm_acle.h to the C++ compile flags allowed the gwenhywfar build to
> complete successfully. 
> 
> For the macOS ARM64 pipeline, inject the
> include only in the environment that builds gwenhywfar or the affected
> dependency group, rather than globally for every package. 
> 
> A
> conservative approach is: 
> 
> 	* 
> 
> apply the workaround only on macOS
> ARM64 jobs;  
> 	* 
> 
> scope it to the dependency build stage that needs it;
> 
> 	* 
> 
> avoid making it a permanent global flag if it can be limited to
> the specific package or platform.  
> 
> The dependency chain stalled before
> KMyMoney itself could be configured. Without the workaround, the
> pipeline never reaches the project build stage. Once the flag was added,
> gwenhywfar completed and the build progressed to the main project.
> 
> 
> This is likely a platform-specific CI environment issue rather than a
> KMyMoney source defect. The important part for developers is that macOS
> ARM64 builds currently need an additional compile-time include to
> satisfy the Qt-related ARM intrinsic reference.
> 
> 
> -------------------------
> 
> After the above changes and workaround, the
> local macOS ARM64 build reached the final packaged application
> successfully. 
> 
> The final successful artifact path was:
> 
> 
> macos-arm-clang/Applications/KDE/kmymoney.app 
> 
> This confirms that the
> pipeline blockers were resolved in sequence: 
> 
> 	* 
> 
> zlib version
> mismatch and dead download fixed.  
> 	* 
> 
> gwenhywfar ARM64 compile issue
> worked around.  
> 	* 
> 
> KMyMoney macOS bundle install rule corrected.  
> 	*
> 
> 
> Full build completed and installed successfully.  
> 
> 
> -------------------------
> 
> The three items to communicate are: 
> 
> 	*
> 
> 
> craft-clone/blueprints/libs/zlib/zlib.py 
> 
> 	* 
> 
> update the supported
> release from 1.3.1 to 1.3.2  
> 	* 
> 
> update the digest for 1.3.2  
> 	*
> 
> 
> remove the obsolete zlib-1.3.1-20240818.diff patch from the 1.3.2
> block  
> 	* 
> 
> reason: upstream 1.3.1 tarball now returns 404 and blocks
> CI immediately  
> 
> 	* 
> 
> kmymoney/CMakeLists.txt 
> 
> 	* 
> 
> add BUNDLE
> DESTINATION ${KDE_INSTALL_BUNDLEDIR} to the install(TARGETS kmymoney
> ...) rule  
> 	* 
> 
> reason: macOS bundle installation failed during
> configure because CMake requires a bundle destination for MACOSX_BUNDLE
> executables  
> 
> 	* 
> 
> macOS ARM64 build environment / Craft configuration
> 
> 
> 	* 
> 
> apply -include arm_acle.h only where needed for the gwenhywfar
> build path  
> 	* 
> 
> reason: gwenhywfar failed on Qt 6 ARM64 because
> __yield() was not declared by the default include set 
> 
> 
> -------------------------
> 
> The local validation established the
> following facts: 
> 
> 	* 
> 
> zlib-1.3.2.tar.xz downloads successfully and the
> tarball contents are valid.  
> 	* 
> 
> gwenhywfar passes once the ARM ACLE
> header workaround is present.  
> 	* 
> 
> kmymoney configures and builds
> successfully after adding the macOS bundle destination.  
> 	* 
> 
> The final
> application bundle is produced under KDE's macOS application path. 
> 
> 
> Hope this could help to fix the Mac Os Pipeline,
> Marco
> 
>  
> 
> 

-- 

Regards

Thomas Baumgart

-------------------------------------------------------------
Life is better when you're laughing. (unknown source)
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 868 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20260415/25ddf19e/attachment-0001.sig>