[package] zlib: conan recipe produces a non-relocatable shared lib on macOS (no LC_ID_DYLIB @rpath/libz.1.dylib)

[SpaceIm]

Package and Environment Details (include every applicable attribute)

• Package Name/Version: zlib/1.2.11
• Operating System+version: Macos Monterey
• Compiler+version: apple-clang 13
• Conan version: conan 1.44.1
• Python version: Python 3.9.10

Conan profile (output of conan profile show default or conan profile show <profile> if custom profile is in use)

[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=13.0
compiler.libcxx=libc++
build_type=Release
[options]
[conf]
[build_requires]
[env]

Steps to reproduce (Include if Applicable)

• conan install zlib/1.2.11@ -o zlib:shared=True -b missing
• cd to install lib dir of zlib
• otool -L libz.1.2.11.dylib

Logs (Include/Attach if Applicable)

currently:

libz.1.2.11.dylib:
	libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

A proper relocatable shared lib should be:

libz.1.2.11.dylib:
	@rpath/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

I won't open an issue for all recipes suffering of this issue, but among key recipes, I've seen at least: zlib, libcurl & openssl.

For zlib there is a simple explanation:

• upstream CMakeLists set a very low min CMake version, which disable rpath in its policy
• even with the proper CMake policy, files are copied manually in the recipe during installation instead of installed properly (install target of CMake is not just a simple copy of files, it properly changes rpath by removing absolute paths set in the build tree and replacing by default everything by @rpath/).