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 ohaya@cox.net designates
 68.230.241.216 as permitted sender)
Message-ID: <20120622150732.5OJQD.197509.imail@eastrmwml214>
Date: Fri, 22 Jun 2012 15:07:32 -0400
From: <ohaya@cox.net>
To: modules-dev@httpd.apache.org
Subject: Re: Followup to earlier thread about "How to compiling/link/use
 Apache module that uses shared library?"
In-Reply-To: <20120622150003.8JHAS.197397.imail@eastrmwml214>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Sensitivity: Normal


---- ohaya@cox.net wrote: 
> 
> ---- Sorin Manolache <sorinm@gmail.com> wrote: 
> > On 2012-06-22 17:35, ohaya@cox.net wrote:
> > 
> > >
> > > Sorry.  I meant to say:
> > >
> > > "So, my code calls ObConfig_initialize() then it appears that that calls
> > > ObConfig::initialize() which is presumably a C++ function. "
> > >
> > 
> > We develop our apache modules in C++ on a regular basis and they 
> > interact with other modules written in plain C and there's no problem.
> > 
> > What I think happens in your case is:
> > 
> > I suspect that the Oracle lib was _statically_ linked with libcrypto. So 
> > the code of some version of libcrypto is in the libobaccess binary. Then 
> > mod_ssl is _dynamically_ linked with libcrypto. I suspect that the two 
> > libcryptos have different versions and they are possibly incompatible => 
> > segfaults at all kind of mallocs/frees. I think it has nothing to do 
> > with new/delete vs malloc/free.
> > 
> > S
> 
> 
> Hi,
> 
> How can I determine whether the libobaccess.so was statically linked with libcrypto?  
> 
> Also, I'll check again, but I think that I checked before using ldd, and both obaccess.so and mod_ssl.so were pointing to the same libcrypto.
> 
> Jim 

Hi,

Sorry, I got confused.  

[root@apachemodule ~]# ldd /apps/httpd2222/modules/mod_ssl.so
        libssl.so.4 => /lib64/libssl.so.4 (0x0000002a95697000)
        libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000002a957d4000)
        libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x0000002a95a05000)
        libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000002a95b1b000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000002a95c8d000)
        libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000002a95d8f000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95eb2000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x0000002a95fb6000)
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a960c9000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a961de000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x0000002a96418000)
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
[root@apachemodule ~]#
[root@apachemodule ~]#
[root@apachemodule ~]# ldd /apps/netpoint/lib64/libobaccess.so
        libnsl.so.1 => /lib64/libnsl.so.1 (0x0000002a95ab8000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000002a95bd0000)
        libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a95cd3000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000002a95de9000)
        libm.so.6 => /lib64/tls/libm.so.6 (0x0000002a95fd9000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000002a9615f000)
        libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9626d000)
        /lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)

Only mod_ssl.so is showing pointer to libcrypto.

Is there a way to determine if libobaccess.so is linked statically to libcrypto, and now showing up in the ldd?

Jim