Does not use system dylib when cross-compiling on macOS

[kornelski]

macOS has fat binary dylibs with executable code for multiple architectures. When cross-compiling between macOS on x86 and ARM, all system libraries are usable on both architectures, including libz.1.dylib.

The current logic gives up on system zlib when target != host, which causes unnecessary static linking when the target and host are x86_64-apple-darwin and aarch64-apple-darwin.

[kornelski]

Detection whether /usr/lib/libz.dylib is actually available as a fat binary is unfortunately complicated, because since macOS 11 all system libraries are part of a monolithic shared cache, and don't exist as individual files in the file system any more (library paths are merely magic keys for lookup in system cache). Apple recommends checking their existence by running dlopen, but that's highly problematic for cross-compilation. For libz it may be enough to just assume it's present.

[kornelski]

Similar issue when cross-compiling to iOS. iOS has libz shared library.

[glandium]

I don't think this is fixed. As a matter of fact I have a cross-compile job that ends up compiling zlib (and failing, because it's using clang trunk, which broke building zlib < 1.3.1).

[Byron]

There is now v1.1.15 of libz-sys with libz 1.3.1 in case this changes anything.