Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
I've now been able to use the latest OpenSSL for mod_ssl while keeping
the system OpenSSL thanks to Ivan Ristic's examples in his books and
tutorials. His method is to compile mod_ssl statically linked with the
latest openssl while compiling all other modules dynamically.
My slightly-modified configure in a bash script looks like this:
SSLDIR=/opt/openssl
export LDFLAGS=-L${SSLDIR}/lib
.
./configure \
--prefix=/usr/local/apache2\
--with-included-apr\
--enable-ssl \
--enable-ssl-staticlib-deps\
--enable-mods-static=ssl \
--with-ssl=${SSLDIR} \
--enable-mods-shared=reallyall \
--with-perl\
--with-python \
--enable-layout=Apache \
--with-pcre=/usr/local/bin/pcre-config \
--without-ldap \
--enable-session-crypto\
--with-crypto
Note the definition of LDFLAGS. During the build, apache uses the
local openssl with no unknown symbol problems. Then, after
installation, apache uses the system openssl, but the important part,
mod_ssl, is still using the local openssl since it was statically
compiled--again, no unknown symbol problems.
.
I have been successfully running Apache 2.4 for some time now with
several virtual https-only sites with no apparent problems.
.
Best regards,
-Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 14.04.2014 13:08, Jeff Trawick wrote:
(not to say there aren't complications, like trying to keep system
directories out of rpath)
Adding my current workarounds for 2.4 here for reference.
Here openssl_libs is either -ldl -lz (Linux) or -lz -ldl -lsocket
-lnsl (Solaris). The value of variables like mysql_path, oracle_path
etc. is always the path to the main installation directory of the component.
One caveat: When building against a non-platform OpenSSL one can run
into a runtime linker problem whenever some other library needed by
httpd has a dependency on the platform OpenSSL. An example is the ldap
library, which is often taken from the platform and is lined against
platform OpenSSL. In that case, both OpenSSL versions are loaded.
So which one is used? Whenever an object (module, library) references a
symbol from OpenSSL the runtime linker searches all loaded objects in
load order, so first the httpd binary, then the libs on which httpd
itself depends, then the modules and there dependencies. The first
symbol definition found will be used. So if there are multiple versions
being loaded, then it is quite possible, that although mod_ssl might
trigger loading of a non-platform OpenSSL lib, the code actually running
later is still the platform OpenSSL code. Let me state it again: a
symbol definition needed by a module will *not* be first searched in
that module or its dependencies, but instead in all loaded objects in
load order.
I personally use -Bsymbolic on the Solaris platform and that plus static
linking on Linux to work around this. But that's possibly to complex for
an average user.
A) apr-util (bundled or standalone):
1) Env Vars
export LDADD_crypto_openssl=$openssl_libs -R${openssl_path}/lib
export LDADD_crypto_nss=-R${nss_path}/lib
export LDADD_dbd_mysql=-R${mysql_path}/lib
export LDADD_dbd_oracle=-R${oracle_path}/lib
Only during configure run (bdb = Berkeley DB)
export LD_LIBRARY_PATH=${bdb_path}/lib
Only during make check run (Oracle libclnt needs libnnz but has no
PATH set itself)
export LD_LIBRARY_PATH=${oracle_path}/lib
2) configure script
For APU crypto support changing all lines of type
LIBS=-lssl -lcrypto ...
to
LIBS=-lssl -lcrypto $openssl_libs ...
(for $openssl_libs see above)
3) Makefile - only when building without dso support
(--disable-util-dso)
Adding rpath, replace
$(LINK) -rpath $(libdir) ...
by
$(LINK) -rpath $(libdir) ${global_rpath} ...
where global_rpath contains - depending on configure flags -
-R${openssl_path}/lib
-R${sqlite_path}/lib
-R${mysql_path}/lib
-R${nss_path}/lib
4) test/Makefile - only when building without dso support
(--disable-util-dso)
Adding rpath, replacing
APRUTIL_LDFLAGS =...
by
APRUTIL_LDFLAGS =... ${global_rpath}
(for global_rpath see 3))
B) HTTPD 2.4
1) Env Vars
Probably not all -L are currently needed:
export MOD_SSL_LDADD=-L${openssl_path}/lib -R${openssl_path}/lib
export MOD_LUA_LDADD=-L${lua_path}/lib -R${lua_path}/lib
export MOD_XML2ENC_LDADD=-L${libxml2_path}/lib -R${libxml2_path}/lib
export MOD_PROXY_HTML_LDADD=-L${libxml2_path}/lib -R${libxml2_path}/lib
export LD_LIBRARY_PATH=${mysql_path}/lib:${oracle_path}/lib
2) configure
Add -lz (OpenSSL dependency), replacing
LIBS=-lssl -lcrypto ...
by
LIBS=-lssl -lcrypto -lz ...
and
ap_openssl_libs=.*apr_config.*
by
ap_openssl_libs=.*apr_config.* -lz
3) support/Makefile
Add -lz (OpenSSL dependency), replacing
ab_LDADD ...
by
ab_LDADD = ... -lz
and because of https support in ab also adding -R${openssl_path}/lib.
Regards,
Rainer
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Apr 14, 2014, at 13:30, Yann Ylavic ylavic@gmail.com wrote: I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl So that should solve the problem I have on Debian where I can't get my version of Apache to use my version of openssl! I tried to remove my system version of OpenSSL but ran into too many dependency issues that I wasn't willing to deal with. Kind regards, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 2014-04-19 10:47, Tom Browder wrote: On Apr 14, 2014, at 13:30, Yann Ylavic ylavic@gmail.com wrote: I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl So that should solve the problem I have on Debian where I can't get my version of Apache to use my version of openssl! I tried to remove my system version of OpenSSL but ran into too many dependency issues that I wasn't willing to deal with. Hi Tom, with apache 2.2.x or 2.4.x ? On FreeBSD 10 (with openssl-1.0.x) in the base system and the same version in the ports we saw a similar issue. LDFLAGS= -L/path/to/ports/openssl/lib was not honored by apache 2.2, but by apache 2.4 and by apr/apr-util The following hack solved this: sed -e s|(ALL_CFLAGS)|(ALL_CFLAGS) -L/path/to/ports/openssl/lib| build/rules.mk.in -- olli
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Fri, Apr 18, 2014 at 2:39 PM, Rainer Jung rainer.j...@kippdata.dewrote: Hi Jeff, On 14.04.2014 13:08, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) See a related discussion from 2011 RUNPATH for module dependencies on Unix/Linux e.g. here: http://markmail.org/message/guastewy5uvn36s7 Joe had some interesting remarks in that discussion. Regards, Rainer Good technical stuff. There are always scary reasons that are bona fide :) People with modest Linux/Unix skills (generally on Linux) often don't know what to do (especially if it seems to work but picks up the wrong library), as the recent go-update-OpenSSL fun demonstrated. It is hard to see that documentation is going to fix this unless we have much more user guide material and somehow draw attention to that. (FWLIW, one can borrow a bit about what libtool knows: libtool --config | grep sys_lib_dlsearch_path_spec) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Apr 19, 2014, at 12:06, olli hauer oha...@gmx.de wrote: Hi Tom, with apache 2.2.x or 2.4.x ? 2.4.7 at the moment but moving to latest release where I'll try forcing the local OpenSSL use. I raised this issue earlier but it got no traction-- probably because I didn't articulate the problem well enough. IMHO the '--with-OpenSSL=' option could benefit from the RPATH nudge suggested by Yann (or at least suggest that move for users unwilling or unable to remove the current system OpenSSL). Regards, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
2.2 2014-04-20 5:13 GMT+08:00, Tom Browder tom.brow...@gmail.com: On Apr 19, 2014, at 12:06, olli hauer oha...@gmx.de wrote: Hi Tom, with apache 2.2.x or 2.4.x ? 2.4.7 at the moment but moving to latest release where I'll try forcing the local OpenSSL use. I raised this issue earlier but it got no traction-- probably because I didn't articulate the problem well enough. IMHO the '--with-OpenSSL=' option could benefit from the RPATH nudge suggested by Yann (or at least suggest that move for users unwilling or unable to remove the current system OpenSSL). Regards, -Tom
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
Hi Jeff, On 14.04.2014 13:08, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) See a related discussion from 2011 RUNPATH for module dependencies on Unix/Linux e.g. here: http://markmail.org/message/guastewy5uvn36s7 Joe had some interesting remarks in that discussion. Regards, Rainer
Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
(not to say there aren't complications, like trying to keep system directories out of rpath) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
I usually force it with ./configure LDFLAGS=-Wl,-rpath -Wl,/path/to/my/openssl. +1 to have this automagically done according to --with-ssl. On Mon, Apr 14, 2014 at 1:08 PM, Jeff Trawick traw...@gmail.com wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 04/14/2014 07:08 AM, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) I think that you're asking for mod_ssl to add an openssl-specific directory to its rpath. in general, i would discourage this; at the least, it needs to be an option that can be easily disabled during ./configure -- libssl and libcrypto should be in the usual system library path, and hard-coding a specific location makes system maintenance unpredictable and more difficult than it needs to be. For a decent overview of the problems with rpath from a distro's perspective: https://wiki.debian.org/RpathIssue Regards, --dkg signature.asc Description: OpenPGP digital signature
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On Mon, Apr 14, 2014 at 8:04 AM, Daniel Kahn Gillmor d...@fifthhorseman.netwrote: On 04/14/2014 07:08 AM, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) I think that you're asking for mod_ssl to add an openssl-specific directory to its rpath. in general, i would discourage this; at the least, it needs to be an option that can be easily disabled during ./configure -- libssl and libcrypto should be in the usual system library path, and hard-coding a specific location makes system maintenance unpredictable and more difficult than it needs to be. For a decent overview of the problems with rpath from a distro's perspective: https://wiki.debian.org/RpathIssue Regards, --dkg We already add rpaths for other libraries in non-standard places (I guess that comes for free with libtool). We wouldn't add rpath to a system directory. I've been all over that document and a bunch of others when needing to remove rpath on various platforms for particular distribution requirements. But that's a different, much smaller group of people than a normal admin/user specifying --with-ssl= and then running into further complications, such as not picking up the expected (fixed) library. A --disable-rpath option would be awesome if indeed it would do that generally. -- Born in Roswell... married an alien... http://emptyhammock.com/ http://edjective.org/
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
On 2014-04-14 13:08, Jeff Trawick wrote: (not to say there aren't complications, like trying to keep system directories out of rpath) On FreeBSD it is possible that a user has openssl 0.9.x or 1.0.x in the base OS (/usr/lib) but installs openssl 1.x.x from the ports system (/usr/local/lib). The OpenSSL version used to build third party applications like apache is then controlled via a flag in /etc/make.conf.
