creating dynamic libraries targeting macosx results in unusable .dylib files

[andrewrk]

• Host: aarch64-macos.12.0.1
• Zig Version: 0.9.0-dev.1759+c9352ef9d

const std = @import("std");
export fn base_address() usize {
    return std.process.getBaseAddress();
}

$ zig build-lib lib.zig -dynamic
error(link): undefined reference to symbol '__mh_execute_header'
error(link):   first referenced in '/Users/andy/tmp/zig-cache/o/e365c75106ca0ae0e6932a78cf567847/lib.o'
error: UndefinedSymbolReference

That's the first problem. But let's work around it by adjusting the zig code:

const std = @import("std");
export fn base_address() usize {
    return 1234;
}

#include <stdio.h>

size_t base_address(void);

int main(int argc, char **argv) {
    fprintf(stderr, "base=%zu\n", base_address());
}

$ cc -o test test.c liblib.dylib
ld: warning: dylib (liblib.dylib) was built for newer macOS version (12.0.1) than being linked (12.0)
$ ./test
dyld[51244]: Library not loaded: @rpath/liblib.dylib
  Referenced from: /Users/andy/tmp/test
  Reason: tried: '/usr/local/lib/liblib.dylib' (no such file), '/usr/lib/liblib.dylib' (no such file)
zsh: abort      ./test

Related issue regarding static libraries: #1981

[artob]

Just got bit by this with 0.6.0. Linking up the related thread on the LLVM mailing list: https://lists.llvm.org/pipermail/llvm-dev/2017-May/112950.html

[andrewrk]

@kubkon did you happen to fix this already?

[kubkon]

@kubkon did you happen to fix this already?

Not sure. I'll check after we land #9387.

[andrewrk]

When I originally filed this issue, the major blocker was the linker. Now that issue is solved but there are still other issues, likely easier to solve than creating a linker from scratch 🙂

I updated the original post above with the behavior that I observed today.

[kubkon]

When I originally filed this issue, the major blocker was the linker. Now that issue is solved but there are still other issues, likely easier to solve than creating a linker from scratch 🙂

I updated the original post above with the behavior that I observed today.

Regarding the second problem, of the loader not being able to find the linked dylib: you need to explicitly specify the @rpath. Note that the same behaviour can be observed using Apple's clang/ld64 and zig cc/ld:

$ zig cc -o test test.c liblib.dylib -Wl,"-rpath=."
$ ./test
base=1234

$ clang -o test test.c liblib.dylib -rpath .
$ ./test
base=1234

I'm investigating the other two now: the __mh_execute_header undefined error, and mismatched platform versions.

[kubkon]

@andrewrk After fixes provided in #10226:

$ cat lib.zig
const std = @import("std");

export fn base_address() usize {
    return std.process.getBaseAddress();
}

$ zig build-lib -dynamic lib.zig
$ clang -o test test.c liblib.dylib -rpath .
$ ./test
base=4336308224

$ zig cc -o test test.c liblib.dylib -Wl,"-rpath=."
$ ./test
base=4379103232