[openssl-users] Symbol(s) not found _TLSv1_2_method _BIO_test_flags

Jeffrey Walton noloader at gmail.com
Mon Jun 13 23:00:10 UTC 2016


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


More information about the openssl-users mailing list