bob 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" \ ADDLIB="-L/opt/prod/openssl11c/lib64 -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 - https://haproxy.org/ ... 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" libssl.so.1.1 => /opt/prod/openssl11c/lib64/libssl.so.1.1 (0x00007efedb62b000) libcrypto.so.1.1 => /opt/prod/openssl11c/lib64/libcrypto.so.1.1 (0x00007efedb125000) not exactly a 'standard' approach to linking, but it solves the problem. thanks! hal