Hi Lukas,
On Sun, Sep 29, 2013 at 10:49:41PM +0200, Lukas Tribus wrote:
> 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?
I'm a bit hesitant here and am not completely fond of what we did for
PCRE_STATIC. The problem is that we force -Wl,-Bstatic then -Wl,-Bdynamic,
and that it breaks full static builds. There's no option in the linker
like "-Wl,-Bdefault" to say "let's come back to the default model", so
we have to force "dynamic" by hand at the end of inclusion of the lib
and complicate the things. For PCRE, the solution consists in using USE_PCRE
instead of USE_STATIC_PCRE when doing a full static build. But if for SSL
we automatically add -ldl, you quickly see the issue happen.
Or maybe we could have a variable "BUILD_MODEL" = {static,dynamic} that
we use to set the fallback mode and take the correct decisions when adding
libraries.
Anyway, I tend to prefer to let people pass an option to fix their build
issues than having a few other ones patch the makefile to get rid of
something that was added for laziness and breaks their build. Let's not
try to reproduce the autotools mess with a makefile :-)
Regards,
Willy
