Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: FW: httpd.exp for Apache 2.0.43
Date: Tue, 3 Jun 2003 18:47:08 +0530
Message-ID: <2B721C6525F0D411B1E900B0D0226BDD0266F9B5@mohmsg01.ad.infosys.com>
Thread-Topic: FW: httpd.exp for Apache 2.0.43
Thread-Index: AcMpyxN8oLxCihGvRzWFBjApxXkBFwABHPbw
From: "Rahul Kohli" <rahul_kohli@infosys.com>
To: <dev@httpd.apache.org>,
	<trawick@attglobal.net>

Thanks Jeff,

Thanks for you inputs.=20

Regarding the function ap_custom_response() , for this we have added our =
own implementation that is specific to apache 2.0 on AIX.

Regards,
> Rahul Kohli

-----Original Message-----
From: Jeff Trawick [mailto:trawick@attglobal.net]
Sent: Tuesday, June 03, 2003 5:47 PM
To: dev@httpd.apache.org
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.
>=20
> Please suggest me how can I  make my library compatible to later =
versions as well. Right now I=20
 >have made a change to remove -G and -brtl option and using apr.exp ,=20
aprutil.exp.exp.
>=20
> The link line is mentioned below:=20
>=20
> /usr/vacpp/bin/makeC++SharedLib_r  -p 0 -bnoipath =
../../Rosette30/unix/lib/aix-xlC_r/libbtunicode.so -b
> 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
>=20
> 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 >=3D 2.0.45

=3D> no issue

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

=3D> users need to create the symlinks libapr.so->libapr-0.so and=20
libaprutil.so->libaprutil-0.so for 2.0.45 and 2.0.46, and we should=20
consider creating the symlinks automatically for future 2.0 releases

If you get run-time linking to work:

=3D> 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=20
from the DSO to see what symbols it is trying to resolve (and whether=20
from main executable or runtime linking or some named library).  The=20
dump output you sent privately when you were building the module with=20
run-time linking had a reference to what looks like a C++-language=20
ap_custom_response():

ap_custom_response__12CExternalApiFP11request_reciPc

Did you resolve that issue?