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
