Process for builing OpenVPN with OpenSSL

[noloader]

This comes up from time to time on Stack Overflow. Folks try to build OpenVPN with OpenSSL but OpenSSL fails to configure properly. Sometimes OpnSSL is provided by the distro in a non-standard location, other times is OpenSSL is installed in a unique location by the user.

OpenVPN's configure dos not appear to honor usual suspects, like --with-ssl=<som dir>. And running configure's help does not provide information on the subject matter.

I've been able to build OpenVPN with custom CFLAGS and CXXFLAGS. But most Autoconf users don't know how to do it; and the process is not exactly documented well. (My apologies if I missed the documentation).

At this point, I've only described the issue. I don't know the best way to solve it. I think a combination of (1) a configure switch to control the SSL/TLS library would be helpful; and (2) documentation on the matter.

I patrol OpenSSL questions on Stack Overflow. Here are three quick results that have to do with building OpenVPN with OpenSSL:

• ​https://stackoverflow.com/questions/41203674/openssl-crypto-library-not-found-during-configure-yet-its-installed
• ​https://stackoverflow.com/questions/38985889/build-openvpn-with-specific-openssl-version
• ​https://stackoverflow.com/questions/28214304/build-openvpn-with-the-modified-openssl

[noloader]

My bad... This:

Folks try to build OpenVPN with OpenSSL but OpenSSL fails to configure properly

Should say:

Folks try to build OpenVPN with OpenSSL but OpnVPN fails to configure properly

[Gert Döring]

INSTALL documents the following options to configure

  OPENSSL_CFLAGS
              C compiler flags for OpenSSL, overriding pkg-config
  OPENSSL_LIBS
              linker flags for OpenSSL, overriding pkg-config

but I do agree that --with-ssl=<dir> or something along that lines would be more in-line with what everyone else does.

We're not going to change that for 2.4 (only bugfixes, and that's not technically a bug but a "questionable design") but we'll revisit right after.

[Steffan Karger]

"In line with what everyone else does" is of course worth something, and I have no clue why we do things differently, but I actually like the current approach. It allows me to just point the *_CFLAGS and *_LIBS to the places where I am building the libraries, without having to run 'make install' after each change.

(That's not a NAK to changing this, just wanted to let you know there's good sides to it too.)

[Gert Döring]

@syzzer: well, developers are a somewhat funny breed, with having half-baked library source trees lying around all across the file system... :-) - but I think we could just have both. Keep the env variables as they are today, and a command line to set them in one go for the "easy" case.

(Same thing for --with-lzo=dir of course)

[Gert Döring]

I'd still like --with-$thing=$dir for lzo, openssl, ... but I'm not going to code it. So just bumping the milestone.