Hi!
>> I should have spotted that earlier on, it was reported to us as Debian >> bug #722777 [1] and it's there because of USE_PCRE; when USE_PCRE is >> enabled, and PCREDIR is not specified, PCRE_LIB will be forced to >> `pcre-config --prefix`/lib (which 99% of the time will be /usr/lib) >> and included in LDFLAGS. If libssl.so is in that path (which will happen >> 99% of the time if PCRE is in the system library path and the system >> does not use multiarch triplets) it will be picked up instead. So in >> this case, it's the relative position of PCRE vs ADDLIB arguments in the >> linker command line that causes ADDLIB to be unable to override system >> libraries by default. > > Yes, that's exactly what is happening. Confirmed. I did not see this because I either compiled without PCRE, or with all paths manually set, so pcre-config was not called. This patch fixes this, of course. Another thing regarding SSL_INC/SSL_LIB: when linking against static openssl, libdl is necessary. Previously I did this by appending ADDLIB with -ldl. It seems like doing the same in SSL_LIB doesn't work (for me), because -ldl must come after -lssl -lcrypto. Now, should we advise users and document to use something like this: SSL_INC=$STATICLIBSSL/include SSL_LIB=$STATICLIBSSL/lib ADDLIB=-ldl Like previsouly suggested by Apollon, we could introduce a flag for statically linking openssl, like we have with PCRE (USE_STATIC_OPENSSL?). If we do that, we could also include -ldl automatically when using that USE flag. Thoughts? Regards, Lukas
