You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/02/03 08:22:44 UTC
Outch, a few problems for 2.0/2.2
1. We've really got to die on ./configure, not make, when we are asked
to --enable-ldap where apr-util wasn't built with ldap. That's bogus;
./configure should describe anticipated problems, not later on.
2. Something's wrong with detection of ssl, even when I explicitly asked
for /usr/local/ssl it's picking up /usr/sfw and I'm not yet sure why.
(Both paths are passed, outch!)
3. We currently abspath the APR_UTIL_LIBS entry for
/path-to/srclib/apr-util/xml/expat/lib/libexpat.la,
but that seriously breaks my AIX vpath builds. I can guess we are
trying to avoid picking up libexpat elsewhere in the -L list, but there's
gotta be a better way for ordering this, and make it consistent
4. The libtool configs are pretty hokey. apr-util properly dereferences the
apr libtool, why don't we do the same on our builtin expat?
5. Also hitting another abspath issue when trying to build apr-util and it's
going for the absolute apr.la, working on that when I go back to AIX
tomorrow.
Finally vpath + symlink builds were broken, there is a set of patches
over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where
-n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding
httpd and apr-util versions. The patches;
* ensure we don't look for srclib/apr*** directories, but simply the
file contained within.
* avoid looking from apr-util to ../apr, since on symlinked environments
in solaris this can be erronious.
* ensure we don't bomb on vpath builds looking for .h files in both the
source and vpath target trees (because they don't exist in both).
* properly check if we are vpath'ing for apr-util/xml/expat, creating that
directory in the vpath target, and introduce the syntax --with-expat=builtin
to resolve the ambiguity that vpath builds of the builtin expat introduces.
* never configure apr-iconv from apr-util. Since we won't configure apr
from apr-util this was inconsistent.
Comments on the proposed patches so far?
Re: Outch, a few problems for 2.0/2.2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
> On 2/2/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>Finally vpath + symlink builds were broken, there is a set of patches
>>over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where
>>-n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding
>>httpd and apr-util versions. The patches;
>
>> * ensure we don't bomb on vpath builds looking for .h files in both the
>> source and vpath target trees (because they don't exist in both).
>
> Consistently looking in one place seems reasonable.
Actually the patch looks in both. We wrap that search in ( ) to avoid make
(solaris make) discovering there was an error invoking ls ap[ru].u, for
example, because those two files exist as generated objects on the target
tree, not the source, while ap[ru]_*.h generally live on the source tree.
>> * never configure apr-iconv from apr-util. Since we won't configure apr
>> from apr-util this was inconsistent.
>
> Assuming you mean buildconf, not configure, +1, I was surprised we did
> this at all. AFAICT the patches don't have anything to do with
> running apr-iconv's configure.
Right; long day yesterday, was in need of caffene replentishment.
Re: Outch, a few problems for 2.0/2.2
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Garrett Rooney wrote:
> On 2/2/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>
>>Finally vpath + symlink builds were broken, there is a set of patches
>>over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where
>>-n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding
>>httpd and apr-util versions. The patches;
>
>> * ensure we don't bomb on vpath builds looking for .h files in both the
>> source and vpath target trees (because they don't exist in both).
>
> Consistently looking in one place seems reasonable.
Actually the patch looks in both. We wrap that search in ( ) to avoid make
(solaris make) discovering there was an error invoking ls ap[ru].u, for
example, because those two files exist as generated objects on the target
tree, not the source, while ap[ru]_*.h generally live on the source tree.
>> * never configure apr-iconv from apr-util. Since we won't configure apr
>> from apr-util this was inconsistent.
>
> Assuming you mean buildconf, not configure, +1, I was surprised we did
> this at all. AFAICT the patches don't have anything to do with
> running apr-iconv's configure.
Right; long day yesterday, was in need of caffene replentishment.
Re: Outch, a few problems for 2.0/2.2
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/2/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Finally vpath + symlink builds were broken, there is a set of patches
> over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where
> -n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding
> httpd and apr-util versions. The patches;
>
> * ensure we don't look for srclib/apr*** directories, but simply the
> file contained within.
Seems reasonable to me...
> * avoid looking from apr-util to ../apr, since on symlinked environments
> in solaris this can be erronious.
+1
> * ensure we don't bomb on vpath builds looking for .h files in both the
> source and vpath target trees (because they don't exist in both).
Consistently looking in one place seems reasonable.
> * properly check if we are vpath'ing for apr-util/xml/expat, creating that
> directory in the vpath target, and introduce the syntax --with-expat=builtin
> to resolve the ambiguity that vpath builds of the builtin expat introduces.
Again, working in vpath builds is a good thing ;-)
> * never configure apr-iconv from apr-util. Since we won't configure apr
> from apr-util this was inconsistent.
Assuming you mean buildconf, not configure, +1, I was surprised we did
this at all. AFAICT the patches don't have anything to do with
running apr-iconv's configure.
In general the APR part of these patches looks reasonable to me,
although I haven't actually tested them. Didn't look at the httpd
side though.
-garrett
Re: Outch, a few problems for 2.0/2.2
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 2/2/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Finally vpath + symlink builds were broken, there is a set of patches
> over on http://people.apache.org/~wrowe/ named fixbuild-n.n.patch where
> -n.n is -2.0 & -0.9, -2.2 & -1.2, and -2.3 & 1.3 for the corresponding
> httpd and apr-util versions. The patches;
>
> * ensure we don't look for srclib/apr*** directories, but simply the
> file contained within.
Seems reasonable to me...
> * avoid looking from apr-util to ../apr, since on symlinked environments
> in solaris this can be erronious.
+1
> * ensure we don't bomb on vpath builds looking for .h files in both the
> source and vpath target trees (because they don't exist in both).
Consistently looking in one place seems reasonable.
> * properly check if we are vpath'ing for apr-util/xml/expat, creating that
> directory in the vpath target, and introduce the syntax --with-expat=builtin
> to resolve the ambiguity that vpath builds of the builtin expat introduces.
Again, working in vpath builds is a good thing ;-)
> * never configure apr-iconv from apr-util. Since we won't configure apr
> from apr-util this was inconsistent.
Assuming you mean buildconf, not configure, +1, I was surprised we did
this at all. AFAICT the patches don't have anything to do with
running apr-iconv's configure.
In general the APR part of these patches looks reasonable to me,
although I haven't actually tested them. Didn't look at the httpd
side though.
-garrett