On Wed, Jul 17, 2019, at 10:06 AM, Zakharychev, Bob wrote:
> rpath is not the best solution here IMO - if the dependency is moved or 
> removed (or replaced with a wrong SO in the right path, maybe even 
> maliciously) from the system haproxy will still fail to load. I 
> personally simply statically link OpenSSL into the HAProxy executable, 
> which makes it portable and independent of OS SO configuration or 
> paths. In order to statically link OpenSSL, simply build it without 
> shared library support (no-shared) and then relink haproxy against it 
> with the same SSL_INC and SSL_LIB. 
> If you still want to use rpath, I believe you can add it with ADDLIB variable:
> make  TARGET=linux-glibc ... ADDLIB="-rpath /opt/prod/openssl111c/lib64"

I don't build OpenSSL statically.  It's part of a production stack I 
manage/distribute with paths to the stack's dynamic libs rpath'd/hardcoded.

So, trying with the ADDLIB/ADDINC you suggest,

        make \
                USE_OPENSSL=1 \
                SSL_LIB="/opt/prod/openssl11c/lib64" \
                SSL_INC="/opt/prod/openssl11c/include" \
-Wl,-rpath,/opt/prod/openssl11c/lib64" \
                ADDINC="-I/opt/prod/openssl11c/include" \

does seem to work,

        /opt/prod/haproxy/sbin/haproxy -vv
                HA-Proxy version 2.0.0 2019/06/16 -
                Built with OpenSSL version : OpenSSL 1.1.1c  28 May 2019
                Running on OpenSSL version : OpenSSL 1.1.1c  28 May 2019
                OpenSSL library supports TLS extensions : yes
                OpenSSL library supports SNI : yes
                OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3

        ldd /opt/prod/haproxy/sbin/haproxy | egrep "ssl|crypto"
       => /opt/prod/openssl11c/lib64/ 
       => /opt/prod/openssl11c/lib64/ 

not exactly a 'standard' approach to linking, but it solves the problem.



Reply via email to