On Mon, Jun 13, 2016 at 6:32 PM, Dan S <danchik at rebelbase.com> wrote: > So I had a suggestion to verify the correct linking by renaming the libssl > and libcrypto built locally to something else, and linking to them- turns > out that was the problem, apparently adding the search path in xcode does > not take priority :( and it was still linking with the distributed old open > ssl that came with 10.6 :( > > So I may just use the renamed files if I can't figure out how to tell the > xcode to ignore the system libraries > Usually you do one of three things. First, you build your shared object with a name. You will see something like this in the Makefile: -install_name "$@" -current_version "$(LIB_MAJOR).$(LIB_MINOR).$(LIB_PATCH)"... Or, you use install_name_tool after you build the shared object to add the name later. This is often used to reset the name after an install. Second, you build as normal but you link against the static library using the fully qualified pathname. You have to use the fully qualified name because the IS X linker always uses the dynamic lib, if available. it becomes an accute problem on iOS, where only the system can supply dynlibs. You will see something like this when linking: clang ... foo.o bar.o /usr/local/ssl/lib/libcrypto.a /usr/local/ssl/lib/libssl.a -o foo.exe This, you run your executable with DYLD_LIBRARY_PATH set (http://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/dyld.1.html): DYLD_LIBRARY_PATH="/usr/local/ssl/lib:$DYLD_LIBRARY_PATH"; ./foo.exe I personally use the second method. After years of fidlling with these issues on multiple platforms, I try to avoid dynamic libraries as much as possible. I want something that "just works" everywhere, and linking against the static archive is the only thing I've found to achieve it. Jeff