Cannot Compile Apache: “Error, SSL/TLS libraries were missing or unusable”

Question

• Arch Linux 2011.08.19 (Linux 3.4.2 i686)
• Apache 2.2.22 → 2.2.22 (recompile & reinstall)
• OpenSSL 1.0.1.c-1

These details are likely irrelevant, but: I’m using yaourt with customizepkg to build Apache from source every time there’s an upgrade available so I can change the suexec docroot to what I want without manually editing the PKGBUILD myself.

In the past this has worked flawlessly; however, it seems that now, for whatever reason, Apache won’t compile. I just did a full system upgrade so that may have something to do with it.

Here is the configure line from the modified PKGBUILD:

../configure --enable-layout=Arch \
    --enable-modules=all \
    --enable-mods-shared=all \
    --enable-so \
    --enable-suexec \
    --with-suexec-caller=http \
    --with-suexec-docroot=/srv/www \
    --with-suexec-logfile=/var/log/httpd/suexec.log \
    --with-suexec-bin=/usr/sbin/suexec \
    --with-suexec-uidmin=99 --with-suexec-gidmin=99 \
    --enable-ldap --enable-authnz-ldap \
    --enable-cache --enable-disk-cache --enable-mem-cache --enable-file-cache \
    --enable-ssl --with-ssl \
    --enable-deflate --enable-cgid \
    --enable-proxy --enable-proxy-connect \
    --enable-proxy-http --enable-proxy-ftp \
    --enable-dbd \
    --with-apr=/usr/bin/apr-1-config \
    --with-apr-util=/usr/bin/apu-1-config \
    --with-pcre=/usr \
    --with-mpm=${mpm}

When I try to build though, it seems to run fine until it gets to the OpenSSL stuff:

mkdir modules/ssl
checking whether to enable mod_ssl... checking dependencies
checking for SSL/TLS toolkit base... none
checking for OpenSSL version... checking openssl/opensslv.h usability... yes
checking openssl/opensslv.h presence... yes
checking for openssl/opensslv.h... yes
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
OK
  forcing SSL_LIBS to "-lssl -lcrypto  "
  adding "-lssl" to LIBS
  adding "-lcrypto" to LIBS
checking openssl/engine.h usability... yes
checking openssl/engine.h presence... yes
checking for openssl/engine.h... yes
checking for SSLeay_version... no
checking for SSL_CTX_new... no
checking for ENGINE_init... no
checking for ENGINE_load_builtin_engines... no
checking for SSL_set_cert_store... no
configure: error: ... Error, SSL/TLS libraries were missing or unusable
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Makepkg was unable to build apache.
==> Restart building apache ? [y/N]
==> -------------------------------
==> 

Googling around, many reported the solution being export LDFLAGS=-ldl, but this has had no effect for me, whether set in the build script or in my bash profile.

Answer 1

Other google searches may lead you to setting some environment variables like these:

$ env LDFLAGS=-ldl

OR

$ export LIBS=-ldl

The first one failed for me and gave me the same error, but the second one worked.

If first one not working for you that because, you need to run the command as single line. As it take the LDFLAGS variable run-time and It will not save.

Ex: env LDFLAGS="-ldl" \ ./configure --prefix=/some/path ...

Answer 2

Looks like httpd configuration is including the wrong version of OpenSSL.

checking for openssl/engine.h... yes
checking for SSLeay_version... no
checking for SSL_CTX_new... no

This can happen if you have multiple installations of OpenSSL. Try setting the --with-ssl option to match the prefix of your latest OpenSSL installation.

--enable-ssl \
--with-ssl=/usr/local \

Answer 3

I had the same problem when upgrading openssl from 0.9.8zb to 1.0.1i.

$/tmp/src/openssl-1.0.1i/ ./config --prefix=/usr/local/openssl -fPIC
$/tmp/src/openssl-1.0.1i/ make test
$/tmp/src/openssl-1.0.1i/ sudo make install

$/tmp/src/httpd-2.2.27/ ./config --enable-so --enable-ssl=shared --with-ssl=/usr/local/openssl
...
$configure: error: ... Error, SSL/TLS libraries were missing or unusable

None of the solutions with setting environment would fix the error message I got.

My solution was:

$/tmp/src/openssl-1.0.1i/ ./config --prefix=/usr/local/openssl-1.0.1 -shared -fPIC
$/tmp/src/openssl-1.0.1i/ make clean
$/tmp/src/openssl-1.0.1i/ make
$/tmp/src/openssl-1.0.1i/ make test
$/tmp/src/openssl-1.0.1i/ sudo make install

$sudo /sbin/ldconfig -v /usr/local/openssl-1.0.1/lib

$/tmp/src/httpd-2.2.27/ make clean && make distclean
$/tmp/src/httpd-2.2.27/ ./configure --enable-so --enable-ssl=shared --with-ssl=/usr/local/openssl-1.0.1
$/tmp/src/httpd-2.2.27/ make
$/tmp/src/httpd-2.2.27/ sudo make install

The problem was fixed by the -shared value in the openssl configuration. Now I'm faced with another problem saying that a sslv2 method is not accessible. But that's not related to this problem, and I don't have an answer for it yet..

I'll continue to search for answers regarding the sslv2 problem and post it to the relevant stackexchange topic when I've solved it.

Answer 4

I don't know if anyone else is having this problem. I run into this issue while creating a script on my mac. The problem was with the openssl compilation. Basically the openssl was being compiled as i386 instead of x86_64.
So I used the openssl configure like this:

./Configure darwin64-x86_64-cc shared --prefix=/usr/local/openssl-1.0.2g

I never had this problem in the office server, because openssl is compiled as x86_64 by default.

Answer 5

This happens because the pkg-config file for openssl no longer specifies a dependency on libdl. Look at newer versions of openssl.pc and you'll see -ldl is no longer included.

This is why setting LIBS=-ldl works (and possibly other approaches that affect shared object use).

According to the CHANGES log, a modification was made in going from 0.9.6h to 0.9.7 such that openssl doesn't always need dynamic shared object loading. I don't believe the change to the openssl.pc file happened at the same time. I haven't found when that change was made.

So I think this is technically a bug in Apache's use of pkg-config to determine the libraries needed to build. I just ran into the same issue trying to build Apache 2.2.31, so the problem has been around for quite a while now.