Opened 3 years ago
Closed 2 years ago
#64488 closed enhancement (fixed)
darktable: add native ARM build
Reported by: | bal-agates | Owned by: | mascguy (Christopher Nielsen) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.2 |
Keywords: | Cc: | MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | |
Port: | darktable |
Description
I was trying to install darktable-devel. For unknown reasons it was rebuilding dependents, at least some, with "+universal". Eventually it ran into a rebuild problem with sqlite3 (see attached sqlite3_config.log) which failed in config. I believe the sqlite3 config problem is separate issue for "+universal" builds where a dependent is specified with a path but that dependent is not a universal (i.e. it is trying to build an x86_64 object including a library that only has an arm64 component).
My fundamental question is: what is causing this to rebuild dependents "+universal"? The darktable-devel portfile defines no universal variant and has "universal_variant no". Is there some dependent port that is triggering this? Is there something in one of the port groups triggering this? How can I debug? I have no use for a universal build. I only want for my computers architecture (i.e. arm64).
Here is a recent build attempt. Note that this does not capture dependent ports that were successfully rebuilt on prior attempts.
$ sudo port install -d -k darktable-devel ---> Computing dependencies for sqlite3 ---> Fetching archive for sqlite3 ---> Attempting to fetch sqlite3-3.37.2_0+universal.darwin_21.arm64-x86_64.tbz2 from https://packages.macports.org/sqlite3 ---> Attempting to fetch sqlite3-3.37.2_0+universal.darwin_21.arm64-x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/sqlite3 ---> Attempting to fetch sqlite3-3.37.2_0+universal.darwin_21.arm64-x86_64.tbz2 from https://mse.uk.packages.macports.org/sqlite3 ---> Configuring sqlite3 Error: Failed to configure sqlite3: consult /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_sqlite3/sqlite3/work/sqlite-autoconf-3370200/config.log Error: Failed to configure sqlite3: configure failure: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_sqlite3/sqlite3/main.log for details. Error: Unable to execute port: upgrade atk failed
I also tried an install disabling universal as follows but that didn't help.
$ sudo port install -d -k darktable-devel -universal
I already have the latest (non-universal) sqlite3 built.
$ port installed | grep sqlite3 sqlite3 @3.37.0_0 sqlite3 @3.37.2_0 (active)
I also tried building darktable @3.6.1 (the non-devel version) and that seemed to have the same problem.
Attachments (2)
Change History (12)
Changed 3 years ago by bal-agates
Attachment: | sqlite3-config.log added |
---|
comment:1 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
The only reason why MacPorts would install dependencies universal (aside from if you requested that) is if that is required. The log shows you are on an Apple Silicon machine but some ports do not yet support being built for Apple Silicon. In that case, they must be built for x86_64 and their dependencies must be built universal for x86_64 and arm64. The darktable-devel portfile contains the line supported_archs x86_64
, therefore all of its dependencies must be built universal. If this line is erroneous, it can be changed. It was added 5 years ago in [4da9bb0fc9bc51a3114ab0a7ca23676c0bb443aa/macports-ports], well before Apple Silicon machines existed, and the commit message doesn't explain why the line was added. You could try removing the line (or adding arm64
to it) and see if it builds and works.
sqlite3 is failing to configure universal because:
ld: in '/opt/local/lib/libunwind.dylib', building for macOS-x86_64 but attempting to link with file built for macOS-arm64
Not sure what to make of that.
comment:2 Changed 3 years ago by bal-agates
Thank you Ryan for the quick analysis. You were correct.
In the Portfile for darktable-devel I added "arm64" to supported_archs. That solved the building "universal" ports issue. Everything now built arm64 without error. However when I ran in a shell I saw the following messages:
$ darktable [dt_detect_cpu_features] Not implemented for this architecture. [dt_detect_cpu_features] Please contribute a patch. [dt_init] SSE2 instruction set is unavailable. [dt_init] expect a LOT of functionality to be broken. you have been warned. (process:40086): GLib-GObject-CRITICAL **: 15:00:42.945: g_object_set: assertion 'G_IS_OBJECT (object)' failed [defaults] found a 64-bit system with 33554432 kb ram and 1 cores (0 atom based) [defaults] setting very conservative defaults dbus[40086]: Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded! [dt_detect_cpu_features] Not implemented for this architecture. [dt_detect_cpu_features] Please contribute a patch. [dt_codepaths_init] will be using experimental plain OpenMP SIMD codepath. [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 [dt_pthread_create] info: bumping pthread's stacksize from 524288 to 2097152 zsh: trace trap darktable
I recognize the SSE2 instruction as only for Intel CPU. See Addressing Architectural Differences in Your macOS Code. I am not sure about the other status but there could be other CPU specific issues. I may look at the CPU issues a little but likely they are more than I can handle.
A prepackaged version of darktable x86_64 is available. I was only trying to build in MacPorts to get a native arm64 version. Do you think we should add a comment to the Portfile referencing this Trac issue in case others fall into the same trap that I did?
Feel free to close this issue.
comment:3 Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | mascguy added |
---|---|
Keywords: | darktable universal sqlite3 removed |
Owner: | set to MarcusCalhoun-Lopez |
Status: | new → assigned |
Summary: | darktable-devel @3.8.0_1: rebuilds dependent ports with "+universal" when that isn't specified → darktable-devel @3.8.0_1: Add native Apple Silicon build |
Type: | defect → enhancement |
I haven't read through all of this upstream issue but someone said in an early comment that adding -DBUILD_SSE2_CODEPATHS=OFF
allowed the build to work on Apple Silicon. You could try adding that (to configure.args
).
You might also file a separate ticket about sqlite3.
comment:4 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:5 Changed 2 years ago by mascguy (Christopher Nielsen)
Cc: | MarcusCalhoun-Lopez added; mascguy removed |
---|---|
Owner: | changed from MarcusCalhoun-Lopez to mascguy |
comment:6 Changed 2 years ago by mascguy (Christopher Nielsen)
Port: | darktable added; darktable-devel removed |
---|---|
Summary: | darktable-devel @3.8.0_1: Add native Apple Silicon build → darktable: add native ARM build |
Version: | 2.7.1 → 2.7.2 |
comment:7 Changed 2 years ago by Christopher Nielsen <mascguy@…>
comment:8 Changed 2 years ago by mascguy (Christopher Nielsen)
Observers: Please leave this ticket open, until we've verified that the ARM build works.
comment:9 Changed 2 years ago by mascguy (Christopher Nielsen)
@bal-agates, can you test with our newly-added ARM support? It's now setup for both darktable
and darktable-devel
- and both are currently identical - so it doesn't matter which one you're using.
comment:10 Changed 2 years ago by mascguy (Christopher Nielsen)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Based on feedback from two different testers - one using the X11 variant, the other Quartz - basic sanity tests look good!
Closing as fixed.
Failed sqlite3 config.log