Hi,
Am 07.04.2016 um 20:52 schrieb Poggenpohl, Daniel:
Hi,
my setup is: I have a Moodle installation I need to run. So I need Apache, PHP, OpenSSL,
iconv, mbstring, curl, zip, etc. . The plan is to have a relatively new PHP (5.6.20) and
stay "new" with Apache and OpenSSL.
Solaris 11.3 seems to come with Apache 2.4.16, PHP 5.3.29, OpenSSL 1.0.1q, curl
7.35.0, OpenLDAP 2.4.30, and others using the official package repository, so I
don't really want to use the official packages for Apache, PHP and OpenSSL.
I tried using another package repository (OpenCSW), which seems to provide
Apache 2.4.18, PHP 5.6.20, curl 7.48.0, OpenSSL 1.0.1s runtime libraries,
OpenLDAP 2.4.40, etc. .The problem there is that officially, the packages have
these release numbers, but when I install PHP via pkgutil, I get 5.3.XX ínstead.
So I decided to compile from source.
I compiled OpenSSL 1.0.2g from source without SSLv2 support (without
enable-ssl2), because I don't really want to have SSLv2 support if I don't need
it.
Compiling Apache with the setup below posed no problem other than httpd not
finding 1.0.2g without LD_LIBRARY_PATH.
But the problems began when I compiled PHP 5.6.20 from source (I will send my
configure call when I'm back at work tomorrow).
Basically, the configure checks curl, uses the system curl which tries to use
one of the functions in OpenSSL 1.0.2g which are gone. So I had to compile curl
7.48.0.
The next problem was the jpeg extension which I solved by setting some -I and
-L options and the PKG_CONFIG_PATH (pointing to the openssl and curl dirs) .
It seems to have used the system curl as well.
Then I had to compile iconv because of unrelated reasons.
Then the zip extension wouldn't work so I had to compile libzip.
And so on and so on.
This all didn't happen when I compiled OpenSSL 1.0.2g with SSLv2 support, by
the way (we deactivated SSLv2 in our Apache anyway, and SSLLabs says we're in
the clear regarding to Drown). With SSLv2 support, PHP's configure finished
without a real warning. And I could build it as well. So I frowned and accepted
SSLv2 support for the moment.
The removal of symbols when SSLv2 support was removed from OpenSSL
1.0.2g happened by accident and was not intended.
Under
https://github.com/openssl/openssl/commit/133138569f37d149ed1d7641fe8c75a93fded445
you can find a simple patch that was already applied to OpenSSL 1.0.2
and will be part of the next version 1.0.2h. You might want to add this
patch to 1.0.2g before compiling. Such an API break is not normal and as
I said happened this time by accident.
By the way, you didn't quote my CPPFLAGS and LDFLAGS that I set. Using LDFLAGS, or rather -R I
understand that I can set the runtime search path when linking the library. When I "ldd -s
httpd", no SSL library is necessary there. And "ldd -s modules/mod_ssl.so" tells me
it finds the locally installed 1.0.2g version. So I still don't understand why I need to set
LD_LIBRARY_PATH when the linker finds what I want.
Since LDFLAGS are used for all linking actions, you might better use
MOD_SSL_LDADD="-R/path/to/openssl/lib"
or as Yann said the more compatible
MOD_SSL_LDADD="-Wl,-rpath -Wl,/path/to/openssl/lib"
For the "ab" support binary if you want to compile it with ssl support,
I think there's also a similar "ab_LDADD" variable and for the crypto
support in the bundled APR 1.5 there's LDADD_crypto_openssl.
Yes, I want to avoid using LD_LIBRARY_PATH, because I read about methods (like
using -R) that could tell libraries where they should look first and
LD_LIBRARY_PATH seems to be a kind of last resort.
Notes:
- Yes, OpenSSL is compiled as a shared library.
- Ideally, I would use /latest links combined with -R to avoid recompiling.
- Do I understand the following right? -I tells the compiler where to look for
headers during compile time. -L tells the compiler where to find libraries to
use in linking during the build. -R tells the Linker where to search for
libraries during runtime.
You did understand it right. See my other post about elfdump/objdump.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
