
- Arch Linux 2011.08.19 (Linux 3.4.2 i686)
- Apache 2.2.22 → 2.2.22 (neu kompilieren und neu installieren)
- OpenSSL 1.0.1.c-1
Diese Details sind wahrscheinlich irrelevant, aber: Ich verwende Yaourt mit Customizepkg, um Apache jedes Mal aus dem Quellcode zu erstellen, wenn ein Upgrade verfügbar ist, sodass ich das Suexec-Docroot nach Wunsch ändern kann, ohne PKGBUILD selbst manuell zu bearbeiten.
In der Vergangenheit hat das einwandfrei funktioniert. Aus irgendeinem Grund scheint Apache jetzt jedoch nicht mehr kompiliert zu werden. Ich habe gerade ein vollständiges Systemupgrade durchgeführt, das könnte also damit zu tun haben.
Hier ist die Konfigurationszeile aus dem geänderten 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}
Beim Erstellen scheint es jedoch problemlos zu laufen, bis ich zum OpenSSL-Zeug komme:
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]
==> -------------------------------
==>
Beim Herumgoogeln berichteten viele, dass die Lösung darin bestehe export LDFLAGS=-ldl
, aber bei mir hatte dies keine Wirkung, egal ob es im Build-Skript oder in meinem Bash-Profil eingestellt war.
Antwort1
Ich hatte das gleiche Problem beim Upgrade von OpenSSL von 0.9.8zb auf 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
Keine der Lösungen zum Festlegen der Umgebung konnte die Fehlermeldung beheben, die ich erhalten habe.
Meine Lösung war:
$/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
Das Problem wurde durch den Wert -shared in der OpenSSL-Konfiguration behoben. Jetzt stehe ich vor einem weiteren Problem, nämlich dass eine SSLV2-Methode nicht zugänglich ist. Aber das hat nichts mit diesem Problem zu tun und ich habe noch keine Antwort darauf.
Ich werde weiterhin nach Antworten zum SSLV2-Problem suchen und es im entsprechenden Stackexchange-Thema posten, wenn ich es gelöst habe.
Antwort2
Bei anderen Google-Suchen können Sie möglicherweise Umgebungsvariablen wie diese festlegen:
$ env LDFLAGS=-ldl
ODER
$ export LIBS=-ldl
Der erste Versuch schlug bei mir fehl und führte zum selben Fehler, aber der zweite Versuch funktionierte.
Wenn der erste Befehl bei Ihnen nicht funktioniert, liegt das daran, dass Sie den Befehl als einzelne Zeile ausführen müssen. Dies nimmt die Laufzeit der Variablen LDFLAGS in Anspruch und wird nicht gespeichert.
Beispiel: env LDFLAGS="-ldl" \ ./configure --prefix=/some/path …
Antwort3
Es sieht so aus, als ob die httpd-Konfiguration die falsche Version von OpenSSL enthält.
checking for openssl/engine.h... yes
checking for SSLeay_version... no
checking for SSL_CTX_new... no
Dies kann passieren, wenn Sie mehrere OpenSSL-Installationen haben. Versuchen Sie, die --with-ssl
Option so einzustellen, dass sie dem Präfix Ihrer neuesten OpenSSL-Installation entspricht.
--enable-ssl \
--with-ssl=/usr/local \
Antwort4
Dies liegt daran, dass die pkg-config-Datei für OpenSSL keine Abhängigkeit von libdl mehr angibt. Sehen Sie sich neuere Versionen von openssl.pc an und Sie werden feststellen, dass -ldl nicht mehr enthalten ist.
Aus diesem Grund LIBS=-ldl
funktioniert das Festlegen von Einstellungen (und möglicherweise auch andere Ansätze, die die Verwendung gemeinsam genutzter Objekte betreffen).
Laut dem CHANGES-Protokoll wurde beim Wechsel von 0.9.6h auf 0.9.7 eine Änderung vorgenommen, sodass OpenSSL nicht immer dynamisches Laden gemeinsam genutzter Objekte benötigt. Ich glaube nicht, dass die Änderung an der Datei openssl.pc gleichzeitig erfolgte. Ich habe nicht herausgefunden, wann diese Änderung vorgenommen wurde.
Ich denke also, dass es sich technisch gesehen um einen Fehler bei der Verwendung von pkg-config durch Apache handelt, um die zum Erstellen benötigten Bibliotheken zu ermitteln. Ich bin gerade beim Versuch, Apache 2.2.31 zu erstellen, auf dasselbe Problem gestoßen, das Problem besteht also schon seit einiger Zeit.