You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Reid <da...@jetnet.co.uk> on 2004/07/13 23:16:40 UTC
1.0.0 RC4
Tarballs available at http://www.apache.org/~dreid/
Test & report!
david
Re: 1.0.0 RC4
Posted by David Reid <da...@jetnet.co.uk>.
> --On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna
<ch...@force-elite.com>
> wrote:
>
> > Failed on FreeBSD 5.2.1-p7:
> > When '--enable-threads' is passed, the final shared object does not link
> > against libc_r:
> >
> > $ ldd .libs/libapr-1.so.0
> > .libs/libapr-1.so.0:
> > libcrypt.so.2 => /lib/libcrypt.so.2 (0x28176000)
>
> It's a bug in the libtool that David rolled with (not a 'bug' but a
'feature'
> in libtool as they try to be our nanny). It strips out libc_r (see around
> line 1358 in David's libtool version).
I actually uninstalled libtool 1.5 from my box and then installed libtool
1.4 before starting to roll the tarballs following Joe Orton's advise that
libtool 1.5 had issues. Go figure.
> However, libtool 1.5.6 from /usr/ports works fine for me (re-run
buildconf).
> We could either document it (as you have to pass --enable-threads to
trigger
> this), or try to upgrade the libtool we roll with. IIRC, there are some
> reasons why we've been avoiding upgrading to 1.5 - so I recommend we
document
> 1.4.3 with --enable-threads on FreeBSD 5.2 is busted for 1.0.0 and figure
out
> libtool 1.5+ for APR 1.1 (or 1.0.1) at this stage of the game. -- justin
I think we should just document this. People can re-run buildconf if they're
on a 5.2.1 system after all.
david
Re: 1.0.0 RC4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, July 14, 2004 4:15 PM +0100 Joe Orton <jo...@redhat.com>
wrote:
> My point is that using "gcc -pthread" may implicitly add the dependency
> on -lc_r, regardless of whether -lc_r is specified on the link line, so
> that's an easy workaround for the libtool behaviour.
FWIW, your patch causes it to build correctly. *shrug* -- justin
Re: 1.0.0 RC4
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jul 14, 2004 at 08:10:33AM -0700, Justin Erenkrantz wrote:
> --On Wednesday, July 14, 2004 9:11 AM +0100 Joe Orton <jo...@redhat.com>
> wrote:
>
> >Does an object created by gcc -pthread -shared have the correct
> >DT_NEEDED fields though? I would expect that APR_PTHREADS_CHECK would
> >work this out correctly, if apr_hints.m4 didn't set
> >apr_cv_pthreads_cflags. Paul, can you try:
>
> We're passing libc_r (via -lc_r) to libtool, but libtool just ignores our
> linking of libc_r. The newer versions of libtool doesn't have that
> particular brain damage. -- justin
My point is that using "gcc -pthread" may implicitly add the dependency
on -lc_r, regardless of whether -lc_r is specified on the link line, so
that's an easy workaround for the libtool behaviour.
Re: 1.0.0 RC4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, July 14, 2004 9:11 AM +0100 Joe Orton <jo...@redhat.com>
wrote:
> Does an object created by gcc -pthread -shared have the correct
> DT_NEEDED fields though? I would expect that APR_PTHREADS_CHECK would
> work this out correctly, if apr_hints.m4 didn't set
> apr_cv_pthreads_cflags. Paul, can you try:
We're passing libc_r (via -lc_r) to libtool, but libtool just ignores our
linking of libc_r. The newer versions of libtool doesn't have that particular
brain damage. -- justin
Re: 1.0.0 RC4
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jul 13, 2004 at 09:22:34PM -0700, Justin Erenkrantz wrote:
> --On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna
> <ch...@force-elite.com> wrote:
>
> >Failed on FreeBSD 5.2.1-p7:
> >When '--enable-threads' is passed, the final shared object does not link
> >against libc_r:
> >
> > $ ldd .libs/libapr-1.so.0
> > .libs/libapr-1.so.0:
> > libcrypt.so.2 => /lib/libcrypt.so.2 (0x28176000)
>
> It's a bug in the libtool that David rolled with (not a 'bug' but a
> 'feature' in libtool as they try to be our nanny). It strips out libc_r
> (see around line 1358 in David's libtool version).
Does an object created by gcc -pthread -shared have the correct
DT_NEEDED fields though? I would expect that APR_PTHREADS_CHECK would
work this out correctly, if apr_hints.m4 didn't set
apr_cv_pthreads_cflags. Paul, can you try:
--- build/apr_hints.m4 8 Jul 2004 10:46:02 -0000 1.67
+++ build/apr_hints.m4 14 Jul 2004 08:08:38 -0000
@@ -147,7 +147,7 @@
apr_cv_pthreads_cflags="none"
apr_cv_pthreads_lib="-lpthread"
else
- apr_cv_pthreads_cflags="-D_THREAD_SAFE -D_REENTRANT"
+ APR_ADDTO(CPPFLAGS, [-D_THREAD_SAFE -D_REENTRANT])
APR_SETIFNULL(enable_threads, [no])
fi
# prevent use of KQueue before FreeBSD 4.8
Re: 1.0.0 RC4
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna <ch...@force-elite.com>
wrote:
> Failed on FreeBSD 5.2.1-p7:
> When '--enable-threads' is passed, the final shared object does not link
> against libc_r:
>
> $ ldd .libs/libapr-1.so.0
> .libs/libapr-1.so.0:
> libcrypt.so.2 => /lib/libcrypt.so.2 (0x28176000)
It's a bug in the libtool that David rolled with (not a 'bug' but a 'feature'
in libtool as they try to be our nanny). It strips out libc_r (see around
line 1358 in David's libtool version).
However, libtool 1.5.6 from /usr/ports works fine for me (re-run buildconf).
We could either document it (as you have to pass --enable-threads to trigger
this), or try to upgrade the libtool we roll with. IIRC, there are some
reasons why we've been avoiding upgrading to 1.5 - so I recommend we document
1.4.3 with --enable-threads on FreeBSD 5.2 is busted for 1.0.0 and figure out
libtool 1.5+ for APR 1.1 (or 1.0.1) at this stage of the game. -- justin
Re: 1.0.0 RC4
Posted by Paul Querna <ch...@force-elite.com>.
On Tue, 2004-07-13 at 22:16 +0100, David Reid wrote:
> Tarballs available at http://www.apache.org/~dreid/
>
> Test & report!
>
Good on FreeBSD 4.5-release.
Good on Lunar-Linux.
Good on FreeBSD-5.2-current. (enabled threads by default, correctly!)
Failed on FreeBSD 5.2.1-p7:
When '--enable-threads' is passed, the final shared object does not link
against libc_r:
$ ldd .libs/libapr-1.so.0
.libs/libapr-1.so.0:
libcrypt.so.2 => /lib/libcrypt.so.2 (0x28176000)
However, using `nm` to look at libapr, it shows that it is looking for
all the undefined pthread_* functions.
The 'libapr-1.la' file shows:
# Libraries that this one depends upon.
dependency_libs=' -lcrypt'
It looks like the recent changes to apr_build.m4(r1.64-r1.67) to disable
threads by default on older FreeBSDs broke the linking for when threads
where enabled?
If you try to build test/testall, it will fail because of undefined
symbols(all the pthread functions). This machine currently has libc_r
globaly mapped to libkse, and it is using a Worker MPM HTTPd perfectly
fine. (built before the changes to apr_build.m4).
If --enable-threads is not passed, RC4 otherwise seems good on FreeBSD-
5.2.1-p7
Not sure if this should be a showstopper. It has worked in this
configuration before. Fix, or release as is?
Also, the tagged CHANGES file is missing the entry for these
apr_build.m4 changes. There is a correct entry in HEAD.
-Paul Querna
Re: 1.0.0 RC4
Posted by Graham Leggett <mi...@sharp.fm>.
David Reid wrote:
> Tarballs available at http://www.apache.org/~dreid/
>
> Test & report!
Tested RPM build on Yellowdog v3.0.1 (LinuxPPC) and it built fine.
+1 again.
Regards,
Graham
--
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:24 PM 7/14/2004, Max Bowsher wrote:
>Joe Orton wrote:
>> On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
>>> David Reid wrote:
>>>> Tarballs available at http://www.apache.org/~dreid/
>>>>
>>>> Test & report!
>>>
>>> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
>to
>>> install apr 0 and apr 1 side-by-side.
>>
>> Known issue, will get fixed sometime after 1.0.0 once everything else
>> has been hooked up to use apr-1-config.
>
>I'm unsure whether my m4 skills are sufficient, but since this is of
>interest to me as I package apr for cygwin, I'm going to work on this, to
>ideally get it done for apr 1.0.0, if I can, if not, helping to get it done
>in 1.0.1 at the latest.
Thank you Max! I know that others and I are all willing to review patches.
Just be prepared for a little give-and-take in getting them approved :)
>Is there anything I've missed out here:
>
>apr: Needs the find_apr.m4 machinery fixed to use apr-1-config.
Sounds right. Folks have asked for a fallback-schema for users who
are willing to code alot of #if (APR_MAJOR_VERSION < 1) code into
their applications. Would be a seperate macro to find apr-1-config,
or if not found, then find apr-config.
>apr-util: Needs to adapt to the changes in apr, and have mirrored changes to
>apu-config
>(Can this wait until after apr-1.0.0, provided it is done soon after?)
I raised this question - and the answer I heard was that apr + -util + -iconv
are all leaving the door together.
>httpd-HEAD: Needs to adapt to the changed find_apr.m4
>(Again, must this be done simultaneously with the apr changes?)
>subversion: No changes, using apr-0.9, at least as the officially supported
>version.
I'm sure these two both need help (including svn head), but it can occur
after APR 1.0.0 is released. Only the warm-fuzzies that it all plays well
together would hold anything up.
I know that mod_jk2 is also very hokey, I need to spend some time over
there after I finish cleaning up some win32 version-foo.
Bill
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re:
1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 15, 2004 12:01 PM -0500 "William A. Rowe, Jr."
<wr...@rowe-clan.net> wrote:
> APR_FIND_APR returns only the first apr found - what 'list of found
> apr's' do you suggest the author validate against to determine where
> apr-1(.1) lives?
They shouldn't. The granularity is at the major level not at the minor or
patch level. If the user wants to override detection, they can shoot
themselves in the foot by passing the path explicitly. -- justin
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re:
1.0.0 RC4 (apr-config -> apr-1-config)
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:09 AM 7/15/2004, Justin Erenkrantz wrote:
>--On Thursday, July 15, 2004 5:34 AM -0700 Noah Misch <no...@cs.caltech.edu> wrote:
>
>>The minimum version field does need to accept two digits. A project could
>>use an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3)
>>would be appropriate and necessary. No?
>
>If a project wants that level of specificity, they can call $apr_config after calling APR_FIND_APR to reject versions they find unsuitable. But, you can't have parallel installs of APR with the same major version number. -- justin
APR_FIND_APR returns only the first apr found - what 'list of found apr's'
do you suggest the author validate against to determine where apr-1(.1)
lives?
Bill
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0
RC4 (apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 15, 2004 9:07 AM -0700 Noah Misch <no...@cs.caltech.edu>
wrote:
> If APR_FIND_APR accepts version constraints, should it not interpret them
> to at least the maximum granularity at which APR allows API changes? I
> think this is not difficult:
I disagree. When you have multiple parallel installs of the same major
version all sorts of things can go wonky.
In your scenario, imagine: /usr having apr-1.1.5 installed and then
/opt/apache having apr-1.2.5 installed. That's going to be a nasty
conflict when the user tries to run it depending upon the characteristics
of the run-time linker (not to mention compiler search order). You might
override the one in /usr/lib with the one in /opt/apache or you might not..
I'd strongly prefer we not open the door to a slew of errors. The
granularity should be at the major version and no finer. -- justin
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Noah Misch <no...@cs.caltech.edu>.
On Thu, Jul 15, 2004 at 08:09:37AM -0700, Justin Erenkrantz wrote:
> --On Thursday, July 15, 2004 5:34 AM -0700 Noah Misch
> <no...@cs.caltech.edu> wrote:
>
> >The minimum version field does need to accept two digits. A project
> >could
> >use an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3)
> >would be appropriate and necessary. No?
>
> If a project wants that level of specificity, they can call $apr_config
> after calling APR_FIND_APR to reject versions they find unsuitable. But,
> you can't have parallel installs of APR with the same major version
> number. -- justin
If APR_FIND_APR accepts version constraints, should it not interpret them to at
least the maximum granularity at which APR allows API changes? I think this is
not difficult:
candidates=
for dir in /usr/local /usr /opt/apache ; do
for c in $dir/bin/apr-config $dir/bin/apr-[[:digit:]]-config ; do
if test -x $c; then candidates="$candidates $c"; fi
done
done
best=
best_ver=-1
for apr_config in $candidates; do
ver=`apr-config --version`
if expr $ver \< $max \& $ver \> $min \& $ver \> $best_ver
best=$apr_config
best_ver=$ver
fi
done
apr_config=$best
...
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0
RC4 (apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 15, 2004 5:34 AM -0700 Noah Misch <no...@cs.caltech.edu>
wrote:
> The minimum version field does need to accept two digits. A project could
> use an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3)
> would be appropriate and necessary. No?
If a project wants that level of specificity, they can call $apr_config after
calling APR_FIND_APR to reject versions they find unsuitable. But, you can't
have parallel installs of APR with the same major version number. -- justin
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jul 15, 2004 at 05:34:33AM -0700, Noah Misch wrote:
> On Thu, Jul 15, 2004 at 11:02:13AM +0100, Joe Orton wrote:
>
> > -dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]])
> > +dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]],
> > +dnl [min-version], [max-version])
>
> > +dnl where min-version and max-version specify the mininum and maximum acceptable
> > +dnl APR major version numbers which can be used, e.g. "0, 1" allows use of
> > +dnl either APR 0.9 or APR 1.0; "1, 1" allows use of only APR 1.0.
>
> The minimum version field does need to accept two digits. A project could use
> an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3) would be
> appropriate and necessary. No?
Sure, that would be useful, much more complicated to implement though
since you have to start parsing the arguments and --version output etc.
Handling just the major version is sufficient for the moment I think...
joe
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Noah Misch <no...@cs.caltech.edu>.
On Thu, Jul 15, 2004 at 11:02:13AM +0100, Joe Orton wrote:
> -dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]])
> +dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]],
> +dnl [min-version], [max-version])
> +dnl where min-version and max-version specify the mininum and maximum acceptable
> +dnl APR major version numbers which can be used, e.g. "0, 1" allows use of
> +dnl either APR 0.9 or APR 1.0; "1, 1" allows use of only APR 1.0.
The minimum version field does need to accept two digits. A project could use
an API added in APR 1.X, in which case e.g. APR_FIND_APR(,,, 1.4, 3) would be
appropriate and necessary. No?
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jul 15, 2004 at 10:38:06AM +0100, Max Bowsher wrote:
> 3) It only implements "accept apr-0 or apr-1", but unless projects do extra
> compatibility work, and make sure to *never* expose the apr ABI in their own
> ABI, they will want "accept apr-0 only" or "accept apr-1 only".
Yes, this is the key problem. Patch below is the logic I like; I
haven't done find_apu.m4.
I don't think it's worth having configure copy ap[ru]-config to
ap[ru]-1-config just to add another failure case here; just assume that
whatever version of APR/util is bundled is a suitable one.
--- build/find_apr.m4 5 Nov 2002 22:09:19 -0000 1.14
+++ build/find_apr.m4 15 Jul 2004 09:54:55 -0000
@@ -6,7 +6,8 @@
dnl embedding APR into the application source, or locating an installed
dnl copy of APR.
dnl
-dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]])
+dnl APR_FIND_APR([srcdir [, builddir, implicit-install-check]],
+dnl [min-version], [max-version])
dnl
dnl where srcdir is the location of the bundled APR source directory, or
dnl empty if source is not bundled.
@@ -17,6 +18,10 @@
dnl where implicit-install-check set to 1 indicates if there is no
dnl --with-apr option specified, we will look for installed copies.
dnl
+dnl where min-version and max-version specify the mininum and maximum acceptable
+dnl APR major version numbers which can be used, e.g. "0, 1" allows use of
+dnl either APR 0.9 or APR 1.0; "1, 1" allows use of only APR 1.0.
+dnl
dnl Sets the following variables on exit:
dnl
dnl apr_found : "yes", "no", "reconfig"
@@ -40,6 +45,15 @@
AC_DEFUN(APR_FIND_APR, [
apr_found="no"
+ apr_minver="$4"
+ apr_maxver="$5"
+ if test -z "${apr_minver}"; then
+ apr_minver=0
+ fi
+ if test -z "${apr_maxver}"; then
+ apr_maxver=1
+ fi
+
if test "$ac_cv_emxos2" = "yes"; then
# Scripts don't pass test -x on OS/2
TEST_X="test -f"
@@ -55,14 +69,19 @@
if test "$withval" = "no" || test "$withval" = "yes"; then
AC_MSG_ERROR([--with-apr requires a directory to be provided])
fi
-
- if $TEST_X "$withval/bin/apr-config"; then
+
+ if test "$apr_maxver" = "1" && $TEST_X "$withval/bin/apr-1-config"; then
+ apr_found="yes"
+ apr_config="$withval/bin/apr-1-config"
+ elif test "$apr_minver" = "0" && $TEST_X "$withval/bin/apr-config"; then
apr_found="yes"
apr_config="$withval/bin/apr-config"
elif $TEST_X "$withval/apr-config"; then
+ # Already-configured build directory: presume version is suitable
apr_found="yes"
apr_config="$withval/apr-config"
elif $TEST_X "$withval" && $withval --help > /dev/null 2>&1 ; then
+ # Full path to apr-config script: presume version is suitable
apr_found="yes"
apr_config="$withval"
fi
@@ -84,13 +103,20 @@
fi
fi
if test "$apr_found" = "no" && test -n "$3" && test "$3" = "1"; then
- if apr-config --help > /dev/null 2>&1 ; then
+ if test "$apr_maxver" = "1" && apr-1-config --help > /dev/null 2>&1 ; then
+ apr_found="yes"
+ apr_config="apr-1-config"
+ elif test "$apr_minver" = "0" && apr-config --help > /dev/null 2>&1 ; then
apr_found="yes"
apr_config="apr-config"
else
dnl look in some standard places (apparently not in builtin/default)
for lookdir in /usr /usr/local /opt/apr /usr/local/apache2 ; do
- if $TEST_X "$lookdir/bin/apr-config"; then
+ if test "$apr_maxver" = "1" && $TEST_X "$lookdir/bin/apr-1-config"; then
+ apr_found="yes"
+ apr_config="$lookdir/bin/apr-1-config"
+ break
+ elif test "$apr_minver" = "0" && $TEST_X "$lookdir/bin/apr-config"; then
apr_found="yes"
apr_config="$lookdir/bin/apr-config"
break
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0
RC4 (apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 15, 2004 6:15 PM +0100 Max Bowsher <ma...@ukf.net> wrote:
> Well, actually, it does. It allows you to build a project against an
> external, built, but uninstalled apr.
>
> William Rowe indicated in IRC that he finds the feature very useful, so
> I'm not going to scrap it when I've already written the code to make it
> continue to work.
No, what you are talking about is what is installed in the builddir. It
doesn't matter. We're going to use it regardless of what major version it
is because the packager decided it was the 'right' version to use. Hence,
adding the -major- detection for the bundled copy is rather pointless and
something Joe caught on in my patch. -- justin
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Thursday, July 15, 2004 10:38 AM +0100 Max Bowsher <ma...@ukf.net>
wrote:
>> 1) It doesn't update configure.in / Makefile.in to name apr-config
>> apr-MAJOR-config in the build directory.
>
> Well, that doesn't matter to our external projects. (And, huh, it's
already
> named like that for me when it's installed.)
Well, actually, it does. It allows you to build a project against an
external, built, but uninstalled apr.
William Rowe indicated in IRC that he finds the feature very useful, so I'm
not going to scrap it when I've already written the code to make it continue
to work.
>> 2) It assumes bundled apr will be apr-1. We want to make find_apr.m4
>> independent of apr version, so that in the future, it could be installed
>> into a system aclocal directory (thanks to noahmcit on #apr for pointing
>> this out).
>
> No, that doesn't matter: if you want to assume bundled APR is less than
1.0,
> use the same find_ap{ru}.m4 you are right now.
Not necessarily. It was suggested on IRC (by noahmcit) that we may want to
consider installing find_apr.m4 to the system aclocal directory, from where
it can transparently fetched into client projects by standard autotools
methods.
>> 3) It only implements "accept apr-0 or apr-1", but unless projects do
extra
>> compatibility work, and make sure to *never* expose the apr ABI in their
own
>> ABI, they will want "accept apr-0 only" or "accept apr-1 only".
>
> Again, not a concern at all. If you want to accept apr-0 *only*, then
don't
> upgrade to this find_ap{ru}.m4.
>
> It's not like all of the projects would magically upgrade to this: they
have
> to choose to upgrade to this m4 version. -- justin
Projects wishing to accept apr-0 only can remain with the old m4. However,
some projects (httpd-HEAD!) will want to accept apr-1 only.
I'm currently testing and writing a changelog for a patch that supports all
the above.
Max.
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0
RC4 (apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, July 15, 2004 10:38 AM +0100 Max Bowsher <ma...@ukf.net> wrote:
> 1) It doesn't update configure.in / Makefile.in to name apr-config
> apr-MAJOR-config in the build directory.
Well, that doesn't matter to our external projects. (And, huh, it's already
named like that for me when it's installed.)
> 2) It assumes bundled apr will be apr-1. We want to make find_apr.m4
> independent of apr version, so that in the future, it could be installed
> into a system aclocal directory (thanks to noahmcit on #apr for pointing
> this out).
No, that doesn't matter: if you want to assume bundled APR is less than 1.0,
use the same find_ap{ru}.m4 you are right now.
> 3) It only implements "accept apr-0 or apr-1", but unless projects do extra
> compatibility work, and make sure to *never* expose the apr ABI in their own
> ABI, they will want "accept apr-0 only" or "accept apr-1 only".
Again, not a concern at all. If you want to accept apr-0 *only*, then don't
upgrade to this find_ap{ru}.m4.
It's not like all of the projects would magically upgrade to this: they have
to choose to upgrade to this m4 version. -- justin
Re: [PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> Tweak find_apr.m4 to look for apr-1-config then look for apr-config. None
of
> these projects you mention need any changes other than a new
find_ap{ru}.m4.
> They all use $apr_config *after* find_ap{ru}.m4 runs. That's why we
designed
> find_ap{ru}.m4 in the way we did - so that changes like this are extremely
> non-intrusive.
>
> Update those find_ap{ru}.m4 in projects that have it, then you're done.
> Completely untested patch attached. I hope my mailer doesn't do anything
> stupid with it, but you should get the gist of it. -- justin
Thanks for the patch, but unfortunately, it has some flaws:
1) It doesn't update configure.in / Makefile.in to name apr-config
apr-MAJOR-config in the build directory.
2) It assumes bundled apr will be apr-1. We want to make find_apr.m4
independent of apr version, so that in the future, it could be installed
into a system aclocal directory (thanks to noahmcit on #apr for pointing
this out).
3) It only implements "accept apr-0 or apr-1", but unless projects do extra
compatibility work, and make sure to *never* expose the apr ABI in their own
ABI, they will want "accept apr-0 only" or "accept apr-1 only".
I'll be writing up an implementation proposal for a set of changes
addressing this, and posting it to this list shortly.
Max.
[PATCH] update find_ap{ru}.m4 for ap{ru}-1-config was Re: 1.0.0 RC4
(apr-config -> apr-1-config)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, July 14, 2004 10:24 PM +0100 Max Bowsher <ma...@ukf.net> wrote:
> Joe Orton wrote:
>> On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
>>> David Reid wrote:
>>>> Tarballs available at http://www.apache.org/~dreid/
>>>>
>>>> Test & report!
>>>
>>> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
> to
>>> install apr 0 and apr 1 side-by-side.
>>
>> Known issue, will get fixed sometime after 1.0.0 once everything else
>> has been hooked up to use apr-1-config.
>
> I'm unsure whether my m4 skills are sufficient, but since this is of
> interest to me as I package apr for cygwin, I'm going to work on this, to
> ideally get it done for apr 1.0.0, if I can, if not, helping to get it done
> in 1.0.1 at the latest.
Tweak find_apr.m4 to look for apr-1-config then look for apr-config. None of
these projects you mention need any changes other than a new find_ap{ru}.m4.
They all use $apr_config *after* find_ap{ru}.m4 runs. That's why we designed
find_ap{ru}.m4 in the way we did - so that changes like this are extremely
non-intrusive.
Update those find_ap{ru}.m4 in projects that have it, then you're done.
Completely untested patch attached. I hope my mailer doesn't do anything
stupid with it, but you should get the gist of it. -- justin
Index: apr/build/find_apr.m4
===================================================================
RCS file: /home/cvs/apr/build/find_apr.m4,v
retrieving revision 1.14
diff -u -r1.14 find_apr.m4
--- apr/build/find_apr.m4 5 Nov 2002 22:09:19 -0000 1.14
+++ apr/build/find_apr.m4 15 Jul 2004 03:38:35 -0000
@@ -56,9 +56,15 @@
AC_MSG_ERROR([--with-apr requires a directory to be provided])
fi
- if $TEST_X "$withval/bin/apr-config"; then
+ if $TEST_X "$withval/bin/apr-1-config"; then
+ apr_found="yes"
+ apr_config="$withval/bin/apr-1-config"
+ elif $TEST_X "$withval/bin/apr-config"; then
apr_found="yes"
apr_config="$withval/bin/apr-config"
+ elif $TEST_X "$withval/apr-1-config"; then
+ apr_found="yes"
+ apr_config="$withval/apr-1-config"
elif $TEST_X "$withval/apr-config"; then
apr_found="yes"
apr_config="$withval/apr-config"
@@ -78,19 +84,26 @@
apr_temp_abs_srcdir="`cd $1 && pwd`"
apr_found="reconfig"
if test -n "$2"; then
- apr_config="$2/apr-config"
+ apr_config="$2/apr-1-config"
else
- apr_config="$1/apr-config"
+ apr_config="$1/apr-1-config"
fi
fi
if test "$apr_found" = "no" && test -n "$3" && test "$3" = "1"; then
- if apr-config --help > /dev/null 2>&1 ; then
+ if apr-1-config --help > /dev/null 2>&1 ; then
+ apr_found="yes"
+ apr_config="apr-1-config"
+ elif apr-config --help > /dev/null 2>&1 ; then
apr_found="yes"
apr_config="apr-config"
else
dnl look in some standard places (apparently not in builtin/default)
for lookdir in /usr /usr/local /opt/apr /usr/local/apache2 ; do
- if $TEST_X "$lookdir/bin/apr-config"; then
+ if $TEST_X "$lookdir/bin/apr-1-config"; then
+ apr_found="yes"
+ apr_config="$lookdir/bin/apr-1-config"
+ break
+ elif $TEST_X "$lookdir/bin/apr-config"; then
apr_found="yes"
apr_config="$lookdir/bin/apr-config"
break
Index: apr-util/build/find_apu.m4
===================================================================
RCS file: /home/cvs/apr-util/build/find_apu.m4,v
retrieving revision 1.7
diff -u -r1.7 find_apu.m4
--- apr-util/build/find_apu.m4 5 Nov 2002 22:13:42 -0000 1.7
+++ apr-util/build/find_apu.m4 15 Jul 2004 03:38:09 -0000
@@ -52,9 +52,16 @@
AC_MSG_ERROR([--with-apr-util requires a directory to be provided])
fi
- if test -x "$withval/bin/apu-config"; then
+ if test -x "$withval/bin/apu-1-config"; then
+ apu_found="yes"
+ apu_config="$withval/bin/apu-1-config"
+ elif test -x "$withval/bin/apu-config"; then
apu_found="yes"
apu_config="$withval/bin/apu-config"
+ elif test -x "$withval/apu-1-config"; then
+ dnl Already configured build dir
+ apu_found="yes"
+ apu_config="$withval/apu-1-config"
elif test -x "$withval/apu-config"; then
dnl Already configured build dir
apu_found="yes"
@@ -76,19 +83,26 @@
if test -d "$1"; then
apu_found="reconfig"
if test -n "$2"; then
- apu_config="$2/apu-config"
+ apu_config="$2/apu-1-config"
else
- apu_config="$1/apu-config"
+ apu_config="$1/apu-1-config"
fi
fi
if test "$apu_found" = "no" && test -n "$3" && test "$3" = "1"; then
- if apu-config --help > /dev/null 2>&1 ; then
+ if apu-1-config --help > /dev/null 2>&1 ; then
+ apu_found="yes"
+ apu_config="apu-1-config"
+ elif apu-config --help > /dev/null 2>&1 ; then
apu_found="yes"
apu_config="apu-config"
else
dnl look in the some standard places (apparently not in
builtin/default)
for lookdir in /usr /usr/local /opt/apr /usr/local/apache2 ; do
- if test -x "$lookdir/bin/apu-config"; then
+ if test -x "$lookdir/bin/apu-1-config"; then
+ apu_found="yes"
+ apu_config="$lookdir/bin/apu-1-config"
+ break
+ elif test -x "$lookdir/bin/apu-config"; then
apu_found="yes"
apu_config="$lookdir/bin/apu-config"
break
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Max Bowsher <ma...@ukf.net>.
Joe Orton wrote:
> On Wed, Jul 14, 2004 at 11:45:31PM +0100, David Reid wrote:
>> OK, so big decision -
>>
>> 1) we delay 1.0.0 until we fix this
>>
>> 2) we aim for a 1.0.1 with this fixed in like 2 weeks or so... (This
would
>> also, inevitably, include some other stuff we don't have in 1.0.0)
>
> I vote (2). This problem has existed forever, requires a fair bit of
> testing to fix properly.
>
> +1 on release of 1.0.0 RC4 tarballs, tested apr and apr-util OK on the
> usual bunch of random boxes here.
Please don't. The problem is nearly solved - I'll have a patch out for
review by the end of today.
As for testing, this is a fairly localized change, fairly easy to review and
be confident of its effects.
Additionally, it requires a change to the arguments of the APR_FIND_APR
autoconf macro. It will be far less painful for external to require
"find_apr.m4 from apr-1" rather than "find_apr.m4 from apr-1.0.1 or later".
APR 1.0 has taken quite a while to happen - it would be a great shame to
push it out the door just ahead of an important interface change.
Max.
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jul 14, 2004 at 11:45:31PM +0100, David Reid wrote:
> OK, so big decision -
>
> 1) we delay 1.0.0 until we fix this
>
> 2) we aim for a 1.0.1 with this fixed in like 2 weeks or so... (This would
> also, inevitably, include some other stuff we don't have in 1.0.0)
I vote (2). This problem has existed forever, requires a fair bit of
testing to fix properly.
+1 on release of 1.0.0 RC4 tarballs, tested apr and apr-util OK on the
usual bunch of random boxes here.
joe
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Graham Leggett <mi...@sharp.fm>.
David Reid wrote:
> OK, so big decision -
>
> 1) we delay 1.0.0 until we fix this
+1.
I get the sense that letting a v1.0.0 go out with this problem will bite
us down the line. I couldn't test the apr rpm builds on my main
development machine because it clashed with httpd as shipped by Redhat
and refused to install. I see lots of potential support emails if apr
can't live side by side with existing software deployments.
I suggest we fix it and try for an RC5.
Regards,
Graham
--
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Max Bowsher <ma...@ukf.net>.
David Reid wrote:
>> Joe Orton wrote:
>>> On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
>>>> David Reid wrote:
>>>>> Tarballs available at http://www.apache.org/~dreid/
>>>>>
>>>>> Test & report!
>>>>
>>>> RC4 is still installing <prefix>/bin/apr-config , so making it
impossible
>>>> to install apr 0 and apr 1 side-by-side.
>>>
>>> Known issue, will get fixed sometime after 1.0.0 once everything else
>>> has been hooked up to use apr-1-config.
>>
>> I'm unsure whether my m4 skills are sufficient, but since this is of
>> interest to me as I package apr for cygwin, I'm going to work on this, to
>> ideally get it done for apr 1.0.0, if I can, if not, helping to get it
done
>> in 1.0.1 at the latest.
>
> OK, so big decision -
>
> 1) we delay 1.0.0 until we fix this
>
> 2) we aim for a 1.0.1 with this fixed in like 2 weeks or so... (This would
> also, inevitably, include some other stuff we don't have in 1.0.0)
>
> Vote early, vote often...
I've examined the situation - there seems to be very little to do to solve
this ! :-)
But, there are some questions I need a consensus on to know how to proceed:
1) Should the apr-config in a *bundled* apr source dir in fact be named
apr-1-config ?
2) Should APR_FIND_APR have a required argument specifying the major version
to look for, *or* should the find_apr.m4 from apr-1.x know that it came from
1.x and so default to looking for apr-1.x ?
2a) If find_apr.m4 needs to know what apr version it came from, is renaming
find_apr.m4 to find_apr.m4.in and doing a sed substituation in buildconf an
acceptable way to achieve this?
Max.
(who will be in #apr on freenode, nick "maxb", when possible, should people
wish to discuss.)
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by David Reid <da...@jetnet.co.uk>.
> Joe Orton wrote:
> > On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
> >> David Reid wrote:
> >>> Tarballs available at http://www.apache.org/~dreid/
> >>>
> >>> Test & report!
> >>
> >> RC4 is still installing <prefix>/bin/apr-config , so making it
impossible
> to
> >> install apr 0 and apr 1 side-by-side.
> >
> > Known issue, will get fixed sometime after 1.0.0 once everything else
> > has been hooked up to use apr-1-config.
>
> I'm unsure whether my m4 skills are sufficient, but since this is of
> interest to me as I package apr for cygwin, I'm going to work on this, to
> ideally get it done for apr 1.0.0, if I can, if not, helping to get it
done
> in 1.0.1 at the latest.
OK, so big decision -
1) we delay 1.0.0 until we fix this
2) we aim for a 1.0.1 with this fixed in like 2 weeks or so... (This would
also, inevitably, include some other stuff we don't have in 1.0.0)
Vote early, vote often...
david
Re: 1.0.0 RC4 (apr-config -> apr-1-config)
Posted by Max Bowsher <ma...@ukf.net>.
Joe Orton wrote:
> On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
>> David Reid wrote:
>>> Tarballs available at http://www.apache.org/~dreid/
>>>
>>> Test & report!
>>
>> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
to
>> install apr 0 and apr 1 side-by-side.
>
> Known issue, will get fixed sometime after 1.0.0 once everything else
> has been hooked up to use apr-1-config.
I'm unsure whether my m4 skills are sufficient, but since this is of
interest to me as I package apr for cygwin, I'm going to work on this, to
ideally get it done for apr 1.0.0, if I can, if not, helping to get it done
in 1.0.1 at the latest.
Is there anything I've missed out here:
apr: Needs the find_apr.m4 machinery fixed to use apr-1-config.
apr-util: Needs to adapt to the changes in apr, and have mirrored changes to
apu-config
(Can this wait until after apr-1.0.0, provided it is done soon after?)
httpd-2.0.x: No changes, uses apr-0.9
httpd-HEAD: Needs to adapt to the changed find_apr.m4
(Again, must this be done simultaneously with the apr changes?)
subversion: No changes, using apr-0.9, at least as the officially supported
version.
Max.
Re: 1.0.0 RC4
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 10:43 AM 7/14/2004, Joe Orton wrote:
>On Wed, Jul 14, 2004 at 04:33:14PM +0100, Max Bowsher wrote:
>> Joe Orton wrote:
>> >> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
>> to
>> >> install apr 0 and apr 1 side-by-side.
>> >
>> > Known issue, will get fixed sometime after 1.0.0 once everything else
>> > has been hooked up to use apr-1-config.
>>
>> Won't that be too late, because of API compat requirements?
>
>Which answer do you prefer? :)
>
>1. No, apr-config is not part of the API
>2. Yes, tough
I was surprised that you missed #3. It's broke - but you get both pieces.
I'm really not teasing - show us the code to fix the complaint.
I do find it incredibly amusing and ironic that the same crew fighting with
"which libtool rev will work?", due to *that* moving target, would endorse
either answer 1. or 2.
But, I have no intentions of installing apr globally on any box, so it doesn't
affect me at all. Every application based on apr that I'm interested in I've
always built against a private apr install. (As I say, I'm a vpath build addict.)
So...
The first group this primarily hurts are devs attempting to build against
either, installed side-by-side (still trusting apr-config? outch, you are broke
on 1.0.1). Document that they must use apr-1-config, they are fine. Ohhh,
also document that they need to rename apr-config out of the way before
1.0 installation, and then copy it back. They are devs, it's not that difficult,
and it gets them ready to build against apr 1.0.1.
The other group this also hurts are OS packagers, who can't ship apr 1.0.0
as designed. Presuming they want to roll in apache 1.3, 2.0, and svn
sometime in the near future, they just need to rejigger the finished set
of files.
The final group, app users, really won't notice. First, by the time they
are ready to adopt an apr 1.0 app, 1.0.1 will be out and this will be fixed,
perhaps. Provided the first two groups don't goof on our account.
So I'm +1 for -beta, -0 for release. I won't block it. But I certainly hope
those, who get so ticked off at the example of libtool's bogosity, would
wish less pain and more consistency for _our_ end users.
Just not looking forward to the day when "Why do my modules fail
to build with apxs (-2.0)" start to show up on users@httpd.
Bill
Re: 1.0.0 RC4
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jul 14, 2004 at 04:33:14PM +0100, Max Bowsher wrote:
> Joe Orton wrote:
> >> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
> to
> >> install apr 0 and apr 1 side-by-side.
> >
> > Known issue, will get fixed sometime after 1.0.0 once everything else
> > has been hooked up to use apr-1-config.
>
> Won't that be too late, because of API compat requirements?
Which answer do you prefer? :)
1. No, apr-config is not part of the API
2. Yes, tough
joe
Re: 1.0.0 RC4
Posted by Max Bowsher <ma...@ukf.net>.
Joe Orton wrote:
> On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
>> David Reid wrote:
>>> Tarballs available at http://www.apache.org/~dreid/
>>>
>>> Test & report!
>>
>> RC4 is still installing <prefix>/bin/apr-config , so making it impossible
to
>> install apr 0 and apr 1 side-by-side.
>
> Known issue, will get fixed sometime after 1.0.0 once everything else
> has been hooked up to use apr-1-config.
Won't that be too late, because of API compat requirements?
Max.
Re: 1.0.0 RC4
Posted by Joe Orton <jo...@redhat.com>.
On Wed, Jul 14, 2004 at 04:12:29PM +0100, Max Bowsher wrote:
> David Reid wrote:
> > Tarballs available at http://www.apache.org/~dreid/
> >
> > Test & report!
>
> RC4 is still installing <prefix>/bin/apr-config , so making it impossible to
> install apr 0 and apr 1 side-by-side.
Known issue, will get fixed sometime after 1.0.0 once everything else
has been hooked up to use apr-1-config.
Re: 1.0.0 RC4
Posted by Max Bowsher <ma...@ukf.net>.
David Reid wrote:
> Tarballs available at http://www.apache.org/~dreid/
>
> Test & report!
RC4 is still installing <prefix>/bin/apr-config , so making it impossible to
install apr 0 and apr 1 side-by-side.
As httpd-2.0.x and subversion-1.x are bound to the 0.9 ABI, it is important
to be able to do this!
Max.
Re: 1.0.0 RC4
Posted by Graham Leggett <mi...@sharp.fm>.
David Reid wrote:
> Tarballs available at http://www.apache.org/~dreid/
>
> Test & report!
RPM builds of apr and apr-util work fine under RHEL3 (you need to rename
the archives to get rid of the -rc4 bit first, but this problem will not
exist in the final release).
+1.
Regards,
Graham
--
Re: 1.0.0 RC4
Posted by Craig Rodrigues <ro...@crodrigues.org>.
On Tue, Jul 13, 2004 at 10:16:40PM +0100, David Reid wrote:
> Tarballs available at http://www.apache.org/~dreid/
Compilation of the apr tests is still broken for MSVC++.
This patch fixes it:
http://issues.apache.org/bugzilla/show_bug.cgi?id=30103
--
Craig Rodrigues
http://crodrigues.org
rodrigc@crodrigues.org