Zig 0.16 macos translate-c issue

Help
, ,
1

I was using version 0.15.2 before. I used the method @cImport(@cInclude(“Accelerate/Accelerate.h”)) to import the interface of Accelerate for usage. Now I’m using the latest version 0.16.0, but here it prompts an error: ‘vImage/vImage.h’ not found. It seems to be a problem with the framework search path. How should I handle this?

zig build run-example-rnn
run-example-rnn
└─ run exe rnn
   └─ compile exe rnn Debug native 3 errors
src/device/host.zig:5:15: error: C import failed
    .macos => @cImport(@cInclude("Accelerate/Accelerate.h")),
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
    matmul__anon_32602: src/device/host.zig:16:13
    matmul__anon_33775: src/tensor.zig:1074:24
    12 reference(s) hidden; use '-freference-trace=14' to see all references
error: translation failure
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.2.sdk/System/Library/Frameworks/Accelerate.framework/Headers/Accelerate.h:28:10: error: 'vImage/vImage.h' not found
#include <vImage/vImage.h>
         ^
error: 3 compilation errors
2

How are you compiling this? Using zig build or zig build-exe ...? In the later case, try to explicitly add -I/path/to/the/Accelerate/dir

3

Just use “zig build”

4

These are the dictionaries:

sdk='/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
frameworks="$sdk/System/Library/Frameworks"
includes="$sdk/usr/include"
libs="$sdk/usr/lib"

You can set sysroot to the SDK path and then do this:

mod.addSystemIncludePath(.{ .cwd_relative = b.pathJoin(&.{ sysroot, "usr/include" }) });
mod.addSystemFrameworkPath(.{ .cwd_relative = b.pathJoin(&.{ sysroot, "System/Library/Frameworks" }) };);
mod.addLibraryPath(.{ .cwd_relative = "/usr/lib" };);

For cross-compilation you can also use this library. (shameless plug)

However, this will likely still not work because you will run into an error caused by Aro not being detected as a valid compiler. I’ve opened a PR for that.

5

Yes, it cannot fix my problem even if I use your repair branch. Is it that aro has some issues with its special handling strategy for header files on macOS?

6

My (uneducated) guess is that the Clang C frontend magically resolves the macOS SDK paths (since when I build the sokol C headers via Zig’s build system I don’t need to provide the macOS SDK path for macOS framework headers to be found), but maybe the Aro frontend used in the translateC mechanism doesn’t have this macOS-specific knowledge.

AFAIK the ‘official’ way to obtain the absolute path to the currently selected macOS SDK is to run xcrun --show-sdk-path and capture stdout. The C sysroot stuff is then in the usr/ subdirectory, and the macOS frameworks are in the System/Library/Frameworks subdirectory

1 Like
7

Maybe you find some hints here:

8

I tried different methods and found that this issue was a bit strange. Since the <Accelerate/Accelerate.h> file, which was directly referenced using @cInclude, could be used normally, there should be a corresponding mechanism in arocc.

However, Accelerate/Accelerate.h again referenced <vImage/vImage.h>, and this time the parsing failed. It seems there is a problem with the nested processing.

9

After reading the relevant code, I identified the cause of the problem.

Zig already adds $(xcrun --show-sdk-path)/System/Library/Frameworks to the framework path by default, so the file Accelerate/Accelerate.c can be directly found. However, vImage/vImage.h is not in this path but in a sub-path under the Accelerate framework. After adding this sub-path, the file Accelerate/Accelerate.c can be parsed normally.

However, another problem arose. arocc by default disables the declaration method of types like

const Pixel_FFFF table[256]

as a function parameter. But vImage uses this writing style, so I need to modify arocc to disable this check. I raised an issue for arocc here: qualifier_non_outermost_array diagnostic is too strict · Issue #994 · Vexu/arocc · GitHub

1 Like