httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Kohli" <>
Subject RE: FW: httpd.exp for Apache 2.0.43
Date Thu, 05 Jun 2003 13:46:05 GMT

Please suggest 

1)  If the 2.0.45 header files will be backwards compatible with apache 2.0.43.

2)  We were able to load library by doing away with -G option  and adding the apr.exp and

The final link line being :

/usr/vacpp/bin/makeC++SharedLib_r  -p 0 -bnoipath ../../Rosette30/unix/lib/aix-xlC_r/
:SRE -berok -bnoentry -blibpath:/usr/lib/threads:/usr/ibmcxx/lib:/usr/lib:/lib -s -bI:/usr/IBMIHS/modules/httpd.exp
-bI:/usr/IBMIHS/lib/apr.exp -bI:/usr/IBMIHS/lib/aprutil.exp -bE:my_lib.exp

Please can you suggest why -G option is preventing our library to load as this flag is required
to produce the shared object. As we are using makeC++SharedLib_r instead of ld.

Thanks for all your help and inputs.


> Rahul Kohli

-----Original Message-----
From: Jeff Trawick []
Sent: Tuesday, June 03, 2003 5:47 PM
Subject: Re: FW: httpd.exp for Apache 2.0.43

Rahul Kohli wrote:

> I was able to resolve the shmmat error by exporting the environment variable EXTSHM.
> Please suggest me how can I  make my library compatible to later versions as well. Right
now I 
 >have made a change to remove -G and -brtl option and using apr.exp , 
> The link line is mentioned below: 
> /usr/vacpp/bin/makeC++SharedLib_r  -p 0 -bnoipath ../../Rosette30/unix/lib/aix-xlC_r/
> M:SRE -berok -bnoentry -blibpath:/usr/lib/threads:/usr/ibmcxx/lib:/usr/lib:/lib -s -bI:/usr/IBMIHS/modules/http
> d.exp -bI:/usr/IBMIHS/lib/apr.exp -bI:/usr/IBMIHS/lib/aprutil.exp -bE:my_lib.exp
> But how can I make this work on 2.0.45 version and later. Kindly suggest.

If you stick with the import file method (httpd.exp, apr.exp, aprutil.exp):

if you build with Apache >= 2.0.45

=> no issue

if you build with Apache >= 2.0.42 (my recommendation, since API is 
unchanged since 2.0.41 and 2.0.42 was the first such GA release)

=> users need to create the symlinks> and> for 2.0.45 and 2.0.46, and we should 
consider creating the symlinks automatically for future 2.0 releases

If you get run-time linking to work:

=> no issue

But I understand that you don't have this method working yet :)

The way I debug DSO loading issues on AIX is to look at the dump output 
from the DSO to see what symbols it is trying to resolve (and whether 
from main executable or runtime linking or some named library).  The 
dump output you sent privately when you were building the module with 
run-time linking had a reference to what looks like a C++-language 


Did you resolve that issue?

View raw message