Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of gregames.apache@gmail.com
 designates 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=Utydj+1aC1dsx5CeVFPxovojtlDX4Zm0HR0lPayxLIha6z6VLehUMPKxSNnItVITl4
         zo8hXLFTKhMzZSdnlLXyNmpZPineBt8Wbg8aWfiUBGYfyY8agSYXvBhtS9LWVJ4v8Npx
         8sTN9yly7LGv0cJehQfMN4Aq0F3Al82jVd4Fc=
Message-ID: <553956a60807101144v4b5256bq519ede488b736bcc@mail.gmail.com>
Date: Thu, 10 Jul 2008 14:44:50 -0400
From: "Greg Ames" <gregames.apache@gmail.com>
To: dev@apr.apache.org
Subject: Re: Adrift with Apache
In-Reply-To: <4874EEB9.7050001@trainersfriend.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <486D0F52.5000006@trainersfriend.com>
	 <553956a60807081502o3a7395f8s93cf76d3cc38fb8f@mail.gmail.com>
	 <4874EEB9.7050001@trainersfriend.com>

On Wed, Jul 9, 2008 at 1:00 PM, Steve Comstock <steve@trainersfriend.com> wrote:

> Hmmm. Seems to me the configure script ought to do the check
> for an existing file,

that's in the patch, but it happens at buildconf time fwiw.

> I picked up autoconf-2.62 from a GNU mirror, but I was reluctant
> to use it; since 2.54 is in toolsNtoys, which is in my PATH, I
> thought that a simpler approach.

I'm looking at mine again and I see autoconf 2.54, not sure what I was
looking at the other day.  maybe it's time for new contacts.  with the
patch on, build tools installed, and $PATH all set for building httpd:

httpd-2.2.9]$ srclib/apr/build/buildcheck.sh
buildconf: checking installation...
buildconf: autoconf version 2.54 (ok)
buildconf: libtool version 1.3.9 (ok)

...i.e. you should be able to use the tool-N-toys autoconf.

> * non-GNU libtool, and you provide a link; but I gather
>   I'm better off to install libtool-zOS-httpd-2.2.tar.Z
>   from the link in this email, right?

yes.  that's what I use with 2.2.  The 2.0 vintage libtool will
probably work with 2.2 also, but more experimenting with env vars etc
may be required, and you will end up with apr and aprutil statically
linked into your apachecore.dll.

> * GNU autocnf and m4; here you provide links, and also
>   these are in the ported tools N toys; which to use?

go with the tools-N-toys versions.  they are more likely to be up to date.

>> I am still bypassing an autoconf version check in pcre, however.
>
> I don't get the meaning of that last sentence.

the patch does that for you.  look in the patch file for something
that hits srclib/pcre/ if you want to know the details.

> I've unwound the tar ball using pax (my surprise: I had
> to do it twice, since the first time I didn't include
> -oto=ibm-1047; I figured this was for an EBCDIC system
> so the stored text would be EBCDCIC. Might want a note
> to that effect).

it also works on BeOS (not EBCDIC).  will do, when I get a round tuit.

> Well, I'll work on those after I get the basic install / port
> done. But now, where do I go?
>
> Here are the pieces I have available:

> My guess is, I need to install the new libtool I just untarred; that is, do a make and make install.

you are very close...the README is your friend

> But then do I need to modify some other code?

yes, modify your httpd source tree with the patch I provided.

> Do I need to do a buildconf?

yes, mainly to hook the z/OS libtool into your source tree.

> A configure?

yes, then make + make install + copy over the libapr[util]-1.so files
into your <prefix>/lib/ dir

> Is build.patch a classic UNIX patch file?

yes.  normally I use unified diffs, but the tools N toys patch program
used to choke (S0C4) on them.  I provided a fix for the patch program
but don't know if it's on the web page or if you have it.  so the
patch was created via diff with no options.

> If so, where do I apply it?

to the top of your source tree, i.e. your unpacked httpd tarball.  you
should be able to tell by looking at the filepaths in the patch file.

Greg