Add "Libs.private: -m" to wolfssl.pc.in for a static linking

[mpsuzuki]

Description

Currently wolfssl.pc returns -lwolfssl only, regardless whether the linking is dynamic or static. libwolfssl uses a few math functions, like log() and pow(), so static linking of libwolfssl needs "-lm" explicitly. Please consider "Libs.private: -lm" to wolfssl.pc.in.

Testing

Before this patch, both of "pkg-config --libs wolfssl" and "pkg-config --libs --static wolfssl" return "-L... -lwolfssl". After this patch, "pkg-confg --libs wolfssl" returns "-L... -lwolfssl", but "pkg-config --libs --static wolfssl" returns "-L... -lwolfssl -lm".

Checklist

• [ ] added tests
• [ ] updated/added doxygen
• [ ] updated appropriate READMEs
• [ ] Updated manual and documentation

[wolfSSL-Bot]

Can one of the admins verify this patch?

[dgarske]

Hi @mpsuzuki ,

The -lm math for pow/log is only required for DH is not using the standard DH P/G params. If you add WOLFSSL_DH_CONST to your build options -lm is not required. Will that solution work for you?

Thanks, David Garske, wolfSSL

[mpsuzuki]

Hi @dgarske,

Thank you for comment. Umm, maybe I failed to describe my intention. I have no problem about the dependency itself, but I want "pkg-config --libs --static" to return appropriate options to link libwolfssl statically.

In my understanding, your comment might be negative to introduce "Libs.private: -lm" to wolfssl.pc. Looking at configure.ac and CMakeLists.txt carefully, I understand the background of your position as follows:

1. It is misunderstanding that wolfSSL is ALWAYS dependent with libm, so hardwiring the dependency into wolfssl.pc is not good.
2. For example, "--enable-dh=const" can build a libwolfssl without a dependency with libm.
3. Also, we should not assume as a math library is ALWAYS named as "libm".

I think my last patch is unacceptable for the viewpoint of the portability, I apologize. Checking configure.ac more carefully, I found that LT_LIB_M (a macro to set LIBM variable pointing a math library, defined by GNU libtool) is invoked if needed, like

# Link with the math library iff needed.
if test "$ENABLED_DH" != "no" && test "$ENABLED_DH" != "const"; then
   LT_LIB_M
fi

Thus, I revised my patch (e4b1e54) as following:

1. Add a variable LIBM to wolfssl.pc.in, and expect a meta-build tool (configure or cmake) set it appropriately before generating wolfssl.pc.
2. Add "AC_SUBST([LIBM])" to configure.ac. LIBM would be blank if LT_LIB_M is not invoked (e.g. ENABLED_DH == "no" or "const"). If invoked, LIBM would have appropriate value to link a math library.
3. Let cmake search "m" in the target link libraries for libwolfssl, and if it is found, let cmake set LIBM.

I cannot find other meta-build tool files caring about wolfssl.pc in IDE directory. Is this more considerable?

[dgarske]

Hi @mpsuzuki ,

The changes look good. Can you tell us more about your project? Are you planning on making additional PR's? For code contributions we required a signed contributor agreement.

Thanks, David Garske, wolfSSL

[mpsuzuki]

Dear @dgarske , Thank you for taking care on this. Please let me know more about required signed agreement. Does it require the signatue of my employer?

Although I made a forked repository to develop my patch, my patches in future (if there is) would be only for the meta-build tools or the compatibility macros for OpenSSL, because I have little expertise in the cryptography, secure network programming. As the educational materials, I wrote a few toy servers for popular TLS implementations (OpenSSL, GnuTLS, BearSSL and wolfSSL) to show the similarities & differences of the APIs. I believe that my patches would be too small to insist some intellectual properties.

[dgarske]

Hi @mpsuzuki ,

I recommend you email support at wolfssl dot com and provide some additional details and request a contributor agreement. Typically you would sign the contributor agreement yourself. It would be great to hear more about your education materials and we will happily support you in efforts involving wolfSSL in those.

Thanks, David Garske, wolfSSL

[embhorn]

@mpsuzuki is approved as a contributor.

[mpsuzuki]

Thank you, @dgarske, @embhorn and @douzzer !