Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (nike.apache.org: domain of jmarantz@google.com designates
 209.85.219.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52B4228E.6080909@kippdata.de>
References: <1387481387726-5010925.post@n6.nabble.com>
 <E413A31B-608C-449E-9975-BF36517884D5@alex.org.uk>
 <52B4228E.6080909@kippdata.de>
From: Joshua Marantz <jmarantz@google.com>
Date: Fri, 20 Dec 2013 08:34:04 -0500
Message-ID: 
 <CAGKR+EDj7vRjDoHJtrH6c8mKadP9b6T53eNeRaNs1=CCcCbp7w@mail.gmail.com>
Subject: Re: problem with different version of openssl in Apache and apache
 module
To: "modules-dev@httpd.apache.org" <modules-dev@httpd.apache.org>
Content-Type: multipart/alternative; boundary=f46d04451a391c05ac04edf75632

--f46d04451a391c05ac04edf75632
Content-Type: text/plain; charset=UTF-8

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.jung@kippdata.de>wrote:

> 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
>

--f46d04451a391c05ac04edf75632--