> OS X side steps the problems with selecting the wrong runtime library > and RPATHs by using something called an install name. Effectively, the > install name should be placed in libcrypto.dylib and libssl.dylib, and > it calls out the fully qualified path name. Programs linked to a > library with an install name will record the library, and dyld(1) will > link to the proper library at runtime. There's no need for tricks like > LD_LIBRARY_PATH on Linux (its called DYLD_LIBRARY_PATH on OS X).
Well, formally speaking the feature was always there, all you needed to do is to pass -Wl,-headerpad_max_install_names at config time ;-) One can argue that it would be appropriate to run `which install_name_tool` in ./config and add the option automatically. Would it be acceptable? I mean would presence of install_name_tool be reliable indicator that linker supports -headerpad_max_install_names? > To make room for an install name that may change (for example, from > PWD to /usr/local/ssl/lib, you need to use the flag > -headerpad_max_install_names on libcrypto.dylib and libssl.dylib. > > To add the icing to the cake, 'make install' should add the following > to its recipe for OS X: > > cp libcrypto.dylib $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib > install_name_tool -id $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib > $(DESTDIR)$(OPENSSLDIR)/lib/libcrypto.dylib Does it really copy libcrypto.dylib and not libcrypto.1.1.dylib? For me it copies the latter... Anyway, the suggested additional step should not be required, because we do pass -install_name when linking .dylib. install_name_tool step would be required if you install it at alternative location, but it doesn't belong in our Makefile. I mean because our Makefile would install in same location as -install_name anyway. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4367 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev