You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@gmail.com> on 2014/04/14 13:08:06 UTC
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?
Posted by Jeff Trawick <tr...@gmail.com>.
On Mon, Apr 14, 2014 at 8:04 AM, Daniel Kahn Gillmor
<dk...@fifthhorseman.net>wrote:
> 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?
Posted by Daniel Kahn Gillmor <dk...@fifthhorseman.net>.
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
Re: Any reason why building with OpenSSL shouldn't add its lib dir
to rpath?
Posted by olli hauer <oh...@gmx.de>.
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.
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Apr 18, 2014 at 2:39 PM, Rainer Jung <ra...@kippdata.de>wrote:
> 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?
Posted by Rainer Jung <ra...@kippdata.de>.
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
Re: Any reason why building with OpenSSL shouldn't add its lib dir to rpath?
Posted by bara bere <ba...@gmail.com>.
2.2
2014-04-20 5:13 GMT+08:00, Tom Browder <to...@gmail.com>:
> On Apr 19, 2014, at 12:06, olli hauer <oh...@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?
Posted by Tom Browder <to...@gmail.com>.
On Apr 19, 2014, at 12:06, olli hauer <oh...@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?
Posted by olli hauer <oh...@gmx.de>.
On 2014-04-19 10:47, Tom Browder wrote:
>> On Apr 14, 2014, at 13:30, Yann Ylavic <yl...@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?
Posted by Tom Browder <to...@gmail.com>.
> On Apr 14, 2014, at 13:30, Yann Ylavic <yl...@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?
Posted by Yann Ylavic <yl...@gmail.com>.
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 <tr...@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?
Posted by Tom Browder <to...@gmail.com>.
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?
Posted by Rainer Jung <ra...@kippdata.de>.
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