http://www.perlmonks.org?node_id=886248


in reply to Link Net::SSLeay to custom-built OpenSSL

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

[download]

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

[download]

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.)

Replies are listed 'Best First'.
Re^2: Link Net::SSLeay to custom-built OpenSSL
by RachunZero (Novice) on Feb 04, 2011 at 17:49 UTC

    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.

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

      IIRC, you can say 

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

      [download]

      (untested)

[reply]
[d/l]
        Thanks again :-) My lazy secular nature made me do: 
        mv Makefile Makefile.tmp
nawk -v d=$OPENSSL_DIR ' /OTHERLDFLAGS =/ { print $0" -R "d"/lib" } ! 
+/OTHERLDFLAGS =/ { print $0 }' Makefile.tmp > Makefile

        [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom