Re: problem with different version of openssl in Apache and apache module
On 19 Dec 2013, at 19:29, Hong wrote: I wrote an Apache module that call functions in openssl library to sign the messages. The module is dynamic linked to openssl library 1.0.1d when I built it. It works fine when it is loaded into the Apache that was also built with the same version of openssl. But if Apache was built with openssl 0.9.8x, segfault occurred. Is there anything I can do for my built so it also works in the Apache which was built with older version of openssl? Static link to openssl? -- Alex Bligh
Re: problem with different version of openssl in Apache and apache module
On 20.12.2013 10:51, Alex Bligh wrote: On 19 Dec 2013, at 19:29, Hong wrote: I wrote an Apache module that call functions in openssl library to sign the messages. The module is dynamic linked to openssl library 1.0.1d when I built it. It works fine when it is loaded into the Apache that was also built with the same version of openssl. But if Apache was built with openssl 0.9.8x, segfault occurred. Is there anything I can do for my built so it also works in the Apache which was built with older version of openssl? Static link to openssl? That often doesn't help, because the runtime linker by default searches symbols in load order. So if mod_ssl was linked against OpenSSL 0.9.8 and mod_xyz was linked against 1.0.1 and mod_ssl gets loaded before mod_xyz, then OpenSSL 0.9.8 gets also loaded before (either as a shared lib or as statically linked into mod_ssl). Now when later the runtime linker needs to resolve an OpenSSL symbol (e.g. function name) because it is used in mod_xyz it will first look in OpenSSL 0.9.8 for the symbol and only if not found there in 1.0.1. AFAIK there's no really good solution. Some platforms support symbolic linking (ld -Bsymbolic), which changes the search order for the runtime linker. With symbolic linking the runtime linker first looks into the dependencies of the component needing a symbol before searching through everything in load order. That means symbols needed by mod_xyz would indeed be searched in OpenSSL 1.0.1 first and in OpenSSL 0.9.8 only as a fallback. Note that this isn't the same as a symbolic file system link. There's a couple of negative side effects though. Another solution should be possible using a linker script but to implement that you would need to do quite a bit of work integrating the linker script into the OpenSSL build. All of this is somehow fragile. It should be more robust to support different combinations with different builds. As pointers have a look at: https://sourceware.org/binutils/docs-2.24/ld/Options.html#Options (short description of ld -Bsymbolic) http://www.akkadia.org/drepper/dsohowto.pdf (search for symbolic, detailed explanations) http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/ http://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects http://docs.oracle.com/cd/E19683-01/817-3677/817-3677.pdf Mostly about Solaris but nevertheless full of interesting stuff. Regards, Rainer
Re: problem with different version of openssl in Apache and apache module
We faced this exact issue (openssl clashes with other linked-in versions)
in mod_pagespeed and ngx_pagespeed, its nginx equivalent.
We solved this problem in our Apache module because we linked
mod_pagespeed.so hiding all the symbols other than the module entry-point
into Apache. Here's the link command:
g++ -shared -pthread -Wl,-z,noexecstack -fPIC \
-Wl,--version-script=build/mod_pagespeed.map \
-Wl,-soname=libmod_pagespeed.so \
-o out/Debug/obj.target/net/instaweb/libmod_pagespeed.so \
-Wl,--start-group \
object file list . \
-Wl,--end-group -lrt
Where mod_pagespeed.map contains:
{
/* Make sure we don't export anything unneeded */
global: pagespeed_module;
local: *;
};
In nginx we didn't have such a clean solution, since nginx just uses a flat
link of .o files. Our resolution is in this script:
https://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/automatic/rename_c_symbols.sh.
This script is specific to our purpose but it might contain enough ideas
that you could hack it to meet yours.
This script is applied to a .a file that includes the definition and use
of a version of openssl. It simply renames all the C symbols in the .a,
leaving the C++ ones intact, and this works for us because the .a in
question has a C++ interface. You could hack the script to just rename the
openssl symbols and your use of them, and you can extract the list of
openssl symbols by grepping the output of nm libopenssl.a, following some
of the patterns in our rename_c_symbols.sh script.
-Josh
On Fri, Dec 20, 2013 at 5:57 AM, Rainer Jung rainer.j...@kippdata.dewrote:
On 20.12.2013 10:51, Alex Bligh wrote:
On 19 Dec 2013, at 19:29, Hong wrote:
I wrote an Apache module that call functions in openssl library to sign
the
messages. The module is dynamic linked to openssl library 1.0.1d when I
built it. It works fine when it is loaded into the Apache that was also
built with the same version of openssl. But if Apache was built with
openssl
0.9.8x, segfault occurred. Is there anything I can do for my built so it
also works in the Apache which was built with older version of openssl?
Static link to openssl?
That often doesn't help, because the runtime linker by default searches
symbols in load order. So if mod_ssl was linked against OpenSSL 0.9.8
and mod_xyz was linked against 1.0.1 and mod_ssl gets loaded before
mod_xyz, then OpenSSL 0.9.8 gets also loaded before (either as a shared
lib or as statically linked into mod_ssl). Now when later the runtime
linker needs to resolve an OpenSSL symbol (e.g. function name) because
it is used in mod_xyz it will first look in OpenSSL 0.9.8 for the symbol
and only if not found there in 1.0.1.
AFAIK there's no really good solution. Some platforms support symbolic
linking (ld -Bsymbolic), which changes the search order for the runtime
linker. With symbolic linking the runtime linker first looks into the
dependencies of the component needing a symbol before searching through
everything in load order. That means symbols needed by mod_xyz would
indeed be searched in OpenSSL 1.0.1 first and in OpenSSL 0.9.8 only as a
fallback. Note that this isn't the same as a symbolic file system link.
There's a couple of negative side effects though.
Another solution should be possible using a linker script but to
implement that you would need to do quite a bit of work integrating the
linker script into the OpenSSL build.
All of this is somehow fragile. It should be more robust to support
different combinations with different builds.
As pointers have a look at:
https://sourceware.org/binutils/docs-2.24/ld/Options.html#Options
(short description of ld -Bsymbolic)
http://www.akkadia.org/drepper/dsohowto.pdf
(search for symbolic, detailed explanations)
http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux/
http://software.intel.com/en-us/articles/performance-tools-for-software-developers-bsymbolic-can-cause-dangerous-side-effects
http://docs.oracle.com/cd/E19683-01/817-3677/817-3677.pdf
Mostly about Solaris but nevertheless full of interesting stuff.
Regards,
Rainer
FreeBSD make
OK... this is weird, FreeBSD 9.2 make doesn't like http://svn.apache.org/viewvc?view=revisionrevision=1327907 gmake works fine. :/ (can't grab what the exact error is right now, but something like needs an operator or something like that... it doesn't like the 'ifdef' statement... or the 'else')
Re: FreeBSD make
On 20 Dec 2013, at 07:04, Jim Jagielski j...@jagunet.com wrote: OK... this is weird, FreeBSD 9.2 make doesn't like http://svn.apache.org/viewvc?view=revisionrevision=1327907 gmake works fine. :/ (can't grab what the exact error is right now, but something like needs an operator or something like that... it doesn't like the 'ifdef' statement... or the 'else') BSD's make needs dot-prefixed .ifdef, .else, and .endif. I don't believe there is a good cross-make compatible way to do this. See http://stackoverflow.com/questions/9096018/make-gmake-compatible-if-else-statment.
Re: FreeBSD make
Currently, configure.in looks like it tries to work around this, but just for BSDI: dnl If we are running on BSD/OS, we need to use the BSD .include syntax. BSD_MAKEFILE=no ap_make_include=include ap_make_delimiter=' ' case $host in *bsdi*) # Check whether they've installed GNU make if make --version /dev/null 21; then true else BSD_MAKEFILE=yes ap_make_include=.include ap_make_delimiter='' fi ;; esac AC_SUBST(ap_make_include) AC_SUBST(ap_make_delimiter) Let me take a look... On Dec 20, 2013, at 9:21 AM, Jim Riggs apache-li...@riggs.me wrote: On 20 Dec 2013, at 07:04, Jim Jagielski j...@jagunet.com wrote: OK... this is weird, FreeBSD 9.2 make doesn't like http://svn.apache.org/viewvc?view=revisionrevision=1327907 gmake works fine. :/ (can't grab what the exact error is right now, but something like needs an operator or something like that... it doesn't like the 'ifdef' statement... or the 'else') BSD's make needs dot-prefixed .ifdef, .else, and .endif. I don't believe there is a good cross-make compatible way to do this. See http://stackoverflow.com/questions/9096018/make-gmake-compatible-if-else-statment.
