--with-openssl-rpath not supported for macos

[LittleBox-x]

Bug report

Bug description:

# Add a code block here, if required

i built python 3.10 on macos m2 device with --with-openssl=/path/to/[email protected] --with-openssl-rpath=auto. i can build it successly. However, ssl.cpython-310-darwin.so depends on the absolute path. as shown below:

CPython versions tested on:

3.10

Operating systems tested on:

macOS

[ronaldoussoren]

See also #110459, the option should work with Python 3.12 and later.

3.10 at this time only receives fixes for security issues, which this isn't.

Also note that -rpath on macOS works different than on Linux, AFAIK the linked to library should have a load path starting with @rpath.

[LittleBox-x]

See also #110459, the option should work with Python 3.12 and later.

3.10 at this time only receives fixes for security issues, which this isn't.

Also note that -rpath on macOS works different than on Linux, AFAIK the linked to library should have a load path starting with @rpath.

Thank you for your answer. However, in my case, using --with-openssl and --with-openssl-rpath can recognize the openssl library and compile successfully. The only problem is that it cannot be ported to other environments because the generated _ssl.cpython-310-darwin.so depends on an absolute path libssl.3.dylib.

[ronaldoussoren]

See also #110459, the option should work with Python 3.12 and later. 3.10 at this time only receives fixes for security issues, which this isn't. Also note that -rpath on macOS works different than on Linux, AFAIK the linked to library should have a load path starting with @rpath.

Thank you for your answer. However, in my case, using --with-openssl and --with-openssl-rpath can recognize the openssl library and compile successfully. The only problem is that it cannot be ported to other environments because the generated _ssl.cpython-310-darwin.so depends on an absolute path libssl.3.dylib.

Does libssl.3.dylib have an @rpath prefix in its install_name, on my system:

% otool -D lib/libcrypto.3.dylib                                                                                                                                  
lib/libcrypto.3.dylib (architecture x86_64):
/Users/ronald/Projects/cpython-dev/build_deps/lib/libcrypto.3.dylib
lib/libcrypto.3.dylib (architecture arm64):
/Users/ronald/Projects/cpython-dev/build_deps/lib/libcrypto.3.dylib

The name shown here is the name included in as a dependency in the _ssl extension. Using install_name_tool to change the id of the library before building Python should do the trick, alternatively use the same tool to rewrite the the load command in the _ssl extension.

I guess we could use install_name_tool to rewrite the load command when --with-openssl-rpath is used. But THB I don't understand what this option tries to accomplish. If I read #87632 correctly the option primarily targets Linux where using custom install prefixes is somewhat annoying when you don't use an rpath.

[ronaldoussoren]

What are you trying to accomplish exactly? Are you trying to build a portable/relocatable installation?

[LittleBox-x]

What are you trying to accomplish exactly? Are you trying to build a portable/relocatable installation?

yes, i want to use it in other mac devices。

[ronaldoussoren]

What are you trying to accomplish exactly? Are you trying to build a portable/relocatable installation?

yes, i want to use it in other mac devices。

Then you'll have to build a copy of openssl where the library id contains @rpath, and have and rpath in the python binary. The latter might not be necessary with --with-openssl-rpath but I haven't tested that. Something like this should do the trick if you have an prebuilt copy of libssl:

$ install_name_tool -id '@rpath/libssl.3.dylib' libssl.3.dylib
$ install_name_tool -add_rpath '@executable_path/../lib' ..../bin/python3.12

That assumes you're using a regular unix install of Python (not a framework build), and copy libssl into the lib directory.

The configure option appears to be for a specific issue on Linux and other ELF using systems, and doesn't really apply to macOS. On macOS we currently do no explicitly support relocatable installations, in the sense that we don't have documentation about creating them.