Link Net::SSLeay to custom-built OpenSSL

[RachunZero]

The instructions for Net::SSLeay say to use the OPENSSL_PREFIX environment variable to set the path to your OpenSSL. If I do that, it seems to find my OpenSSL:

*** Found OpenSSL-0.9.8p installed in /dsk01/apache/app/build2064/open
+ssl-0.9.8p

But it creates a mangled SSLeay.so:

# ldd SSLeay.so
        libssl.so.0.9.8 =>       (file not found)
        libcrypto.so.0.9.8 =>    (file not found)
        libz.so.1 =>     /usr/lib/libz.so.1
        libc.so.1 =>     /lib/libc.so.1
        libm.so.2 =>     /lib/libm.so.2

If I omit the OPENSSL_PREFIX, it finds the /usr/sfw/bin/openssl and creates a happy library:

ldd /dsk01/apache/download/build2064/perl_modules-20101126/Net-SSLeay-
+1.36/blib/arch/auto/Net/SSLeay/SSLeay.so
        libssl.so.0.9.7 =>       /usr/sfw/lib/libssl.so.0.9.7
        libcrypto.so.0.9.7 =>    /usr/sfw/lib/libcrypto.so.0.9.7
        libz.so.1 =>     /usr/lib/libz.so.1
        libc.so.1 =>     /lib/libc.so.1
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libssl_extra.so.0.9.7 =>         /usr/sfw/lib/libssl_extra.so.
+0.9.7
        libcrypto_extra.so.0.9.7 =>      /usr/sfw/lib/libcrypto_extra.
+so.0.9.7
        libm.so.2 =>     /lib/libm.so.2

My compile script looks like:

PERL_DIR=/dsk01/apache/app/build2064/perl-5.12.2
PL=$PERL_DIR/bin/perl
cd Net-SSLeay-1.36
$PL Makefile.PL PREFIX=$PERL_DIR -n
make clean
OPENSSL_PREFIX=$OPENSSL_DIR \
$PL Makefile.PL
make; make test; make install

and the important output is

/dsk01/apache/app/build2064/perl-5.12.2/bin/perl "-Iinc" /dsk01/apache
+/app/build2064/perl-5.12.2/lib/5.12.2/ExtUtils/xsubpp  -typemap /dsk0
+1/apache/app/build2064/perl-5.12.2/lib/5.12.2/ExtUtils/typemap -typem
+ap typemap  SSLeay.xs > SSLeay.xsc && mv SSLeay.xsc SSLeay.c
gcc -c  -I/dsk01/apache/app/build2064/openssl-0.9.8p/include -I/dsk01/
+apache/app/build2064/openssl-0.9.8p/inc32 -I/usr/kerberos/include -D_
+REENTRANT -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFIL
+E_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV -O2 -g   -DVER
+SION=\"1.36\" -DXS_VERSION=\"1.36\" -fPIC "-I/dsk01/apache/app/build2
+064/perl-5.12.2/lib/5.12.2/i86pc-solaris-thread-multi/CORE"   SSLeay.
+c
Running Mkbootstrap for Net::SSLeay ()
LD_RUN_PATH="/dsk01/apache/app/build2064/openssl-0.9.8p/lib:/usr/lib" 
+gcc  -G -L/usr/local/lib SSLeay.o  -o blib/arch/auto/Net/SSLeay/SSLea
+y.so         \
   -L/dsk01/apache/app/build2064/openssl-0.9.8p -L/dsk01/apache/app/bu
+ild2064/openssl-0.9.8p/lib -lssl -lcrypto -lz     \
...
PERL_DL_NONLAZY=1 /dsk01/apache/app/build2064/perl-5.12.2/bin/perl "-M
+ExtUtils::Command::MM" "-e" "test_harness(0, 'inc', 'blib/lib', 'blib
+/arch')" t/local/*.t t/handle/local/*.t
t/handle/local/05_use.t ........ 1/1
#   Failed test 'use Net::SSLeay::Handle;'
#   at t/handle/local/05_use.t line 8.
#     Tried to use 'Net::SSLeay::Handle'.
#     Error:  Can't load '/dsk01/apache/download/build2064/perl_module
+s-20101126/Net-SSLeay-1.36/blib/arch/auto/Net/SSLeay/SSLeay.so' for m
+odule Net::SSLeay: ld.so.1: perl: fatal: libssl.so.0.9.8: open failed
+: No such file or directory at /dsk01/apache/app/build2064/perl-5.12.
+2/lib/5.12.2/i86pc-solaris-thread-multi/DynaLoader.pm line 200.

Does anyone have any insight as to why my custom OpenSSL isn't linking in properly?

[Anonyrnous Monk]

LD_RUN_PATH="/dsk01/apache/app/build2064/openssl-0.9.8p/lib:/usr/lib" 
+...

You might want to check:

(a) if your libssl.so does in fact live in the above RUNPATH .../openssl-0.9.8p/lib,  and (b) if that path is actually being written to SSLeay.so. Check RUNPATH/RPATH settings with

$ dump -Lv .../SSLeay.so

The theory is that the linker (ld) puts the lib search path(s) into the .so (or binary), and the dynamic linker (ld.so.1) then picks it up from there...

(See also LD_RUN_PATH, and the option -R, in the ld man page.)

[RachunZero]

Oh. That's it. Thanks!

I forgot that the gcc packaged in Solaris 10 doesn't do runpaths properly using the environment variable. It's only got /usr/sfw/lib showing in the runpath header.

If I want a proper runpath, I have to explicitly pass it in -R parameters to gcc.

Hmmm... I wonder what I do now. Can I change the gcc options? Makefile.PL seems to ignore LDFLAGS.

[Anonyrnous Monk]

Can I change the gcc options? Makefile.PL seems to ignore LDFLAGS.

IIRC, you can say

    dynamic_lib => { OTHERLDFLAGS => '-R...' }

(untested)