Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? The entire httpd/apr-util/apr build system rests on the *-config scripts, for better or worse (usually the latter). joe
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Max.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote: Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. joe
Re: cvs commit: apr/strings apr_strings.c
David Reid wrote:
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when the buffer would overflow.
Backport of rev 1.47
Reviewed by: trawick
reviewed but not approved ;)
it still has the same bug (apr_snprintf() doesn't return 0 either)
Care to supply a fixed version?
IMHO the original version is sufficient for now. In fact, the new version
isn't going to misbehave; it just introduces dead code.
One way of implementing the spirit of what Bill Rowe was trying to do would
require looking at the generated buffer instead of the return code from
sprintf/apr_snprintf.
For example, change
sprintf(buf, %3d , (int) size);
to
apr_snprintf(buf, 5, %3d , (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, );
}
(For the other changes we'd have to look for the final 'c' in a certain
position to detect overflow.)
Alternatively, apr_snprintf into a larger local buffer to be able to detect
overflow of a 5-byte buffer by looking at the apr_snprintf() return code, and
if okay copy the output to the caller's buffer before returning.
Note that libc has to have broken sprintf() or somebody has to introduce a new
bug into the apr_strfsize() function in order to have such an overflow anyway.
Due to the API, we can't catch the problem where the caller passes a buffer
which is not large enough.
Re: cvs commit: apr/strings apr_strings.c
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote: IMHO the original version is sufficient for now. Agreed. .. Note that libc has to have broken sprintf() or somebody has to introduce a new bug into the apr_strfsize() function in order to have such an overflow anyway. Due to the API, we can't catch the problem where the caller passes a buffer which is not large enough. And the person who screws up the code in the future may also screw up and remove the snprintf calls when they work out they are redundant. Adding tests seems like the best way to protect against someone screwing up in the future... joe
Re: cvs commit: apr/strings apr_strings.c
Joe Orton wrote: On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote: IMHO the original version is sufficient for now. Agreed. Adding tests seems like the best way to protect against someone screwing up in the future... yes, that makes perfect sense to me
apr 1.0 rc2
Tagged! The files that have changed since RC1 are as follows (if any are missing please yell!) Makefile.in configure.in CHANGES STATUS docs/doxygen.conf include/apr_file_info.h include/apr_thread_proc.h shmem/beos/shm.c test/abts.c test/testlock.c test/teststr.c test/testutil.c test/testprocmutex.c threadproc/beos/proc.c threadproc/os2/proc.c threadproc/unix/proc.c threadproc/win32/proc.c I didn't updated the tag on network_io/unix/sockaddr.c to 1.53 as the change did provoke some comments about it's validity. As it was just the addition of a comment I figure it's safe to leave out :-) I'll roll later on this afternoon. david
apr-util 1.0 rc2
Tagged! Files that have been updated since RC1 are as follows apr-util.pc.in Makefile.in STATUS docs/doxygen.conf test/testutil.c test/testutil.h test/testuri.c test/teststrmatch.c test/testpass.c test/testbuckets.c test/abts_tests.h test/Makefile.in I haven't (intentioally) included teh EBIDIC stuff that was committed. If people want it to be included then the tags can be bumped - not a big deal. david
Re: cvs commit: apr/strings apr_strings.c
Jeff Trawick wrote:
reviewed but not approved ;)
it still has the same bug (apr_snprintf() doesn't return 0 either)
Care to supply a fixed version?
IMHO the original version is sufficient for now. In fact, the new version
isn't going to misbehave; it just introduces dead code.
One way of implementing the spirit of what Bill Rowe was trying to do would
require looking at the generated buffer instead of the return code from
sprintf/apr_snprintf.
For example, change
sprintf(buf, %3d , (int) size);
to
apr_snprintf(buf, 5, %3d , (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, );
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we check that the return value is =
the actual buffer size?
--
===
Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/
A society that will trade a little liberty for a little order
will lose both and deserve neither - T.Jefferson
Re: cvs commit: apr/strings apr_strings.c
apr_snprintf(buf, 5, %3d , (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, );
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we check that the return value is =
the actual buffer size?
And apr_snprintf() tells us the same if len is 0.
Re: apr 1.0 rc2
On Wed, Jun 30, 2004 at 12:32:20PM +0100, David Reid wrote: Tagged! The files that have changed since RC1 are as follows (if any are missing please yell!) Just a reminder that the version should always be 1.0.0 with all three components, not 1.0, even in tags... joe
1.0 rc2 Tarballs
Available at http://www.apache.org/~dreid/ I haven't done apr-iconv as Will Rowe had some reservations about that module. If someone who's more familiar wants to roll a tarball that's compatible with rc2 that'd be great. They have just 1.0 in the filenames (sorry Joe) but that'll be fixed for the final roll. Now, can people test them and we'll see if we get enough +1's ? If I see enough +1's by Friday then I'll plan on rolling a final 1.0 on Friday, but I'll be out of contact until then :-( david
Re: cvs commit: apr-util/xml apr_xml.c
On Wed, Jun 23, 2004 at 04:10:58PM +0200, jean-frederic clere wrote: Why take a convset if this can only convert to EBCDIC? You know that the tree is in UTF-8 so there is no other variable for the caller to control. The convset I have used is ap_hdrs_from_ascii. (APR_DEFAULT_CHARSET, ISO8859-1) that is fixed. It's broken then - the XML parser returns UTF-8. It looks like the code will silently corrupt any part of the DOM tree which can't be entirely converted to EBCDIC, since it ignores the _conv_buffer return values, which doesn't seem acceptable to me. joe
Re: 1.0 rc2 Tarballs
At 07:06 AM 6/30/2004, David Reid wrote: I haven't done apr-iconv as Will Rowe had some reservations about that module. If someone who's more familiar wants to roll a tarball that's compatible with rc2 that'd be great. Doesn't matter - now that you've tagged apr-util-1.0.0 - we are locked into using that apr-iconv interface period for apr-iconv-1.0.0. All I'd suggested at this juncture is to add some notatation that the apr_iconv_ functions are private interfaces, e.g. @deprecated Private Interface! See the apr-util apr_xlate.h API. Can we get some +1's on this? IMHO we can't release this tarball without moving to apr-1-config as mentioned in the apr pkgconfig thread. This allows us to have 0.9 and 1.0 installed side by side, e.g. if httpd and svn users are building both older and newer software. While they cannot be installed side by side, I'm -1 for release; once addressed I'm +1.
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
At 03:56 AM 6/30/2004, Joe Orton wrote: On Wed, Jun 30, 2004 at 09:49:48AM +0100, Max Bowsher wrote: Joe Orton wrote: On Tue, Jun 29, 2004 at 03:11:30PM -0400, Greg Hudson wrote: ... So, please change the recently added pkgconfig support to install apr-1.pc, so that upstream packages will run pkg-config --libs apr-1 instead of just looking for any old version of APR. By itself, that won't help with the APR 0.9 to APR 1.x transition, but it will help with APR 1.x to APR 2.x. Yeah, I realised the same thing... I'll rename it. Separately, I will request that APR remove apr-config from APR 1.0 and later in order to correctly manage the APR 0.9 - APR 1.0 transition, but I bet that won't fly. APR cannot mandate presence of pkgconfig, so do you have an alternative? Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Hmmm... If an app is written to support apr 2, 1 or 0, wouldn't a sanity check for the presence of apr-2-confiig / apr-1-config / apr-config solve this? Leave installed apr-config as a presumed-rev 0.9.x installed version. Now that Max mentions this - I have tripped over it once before. Bill
Re: 1.0 rc2 Tarballs
At 07:06 AM 6/30/2004, David Reid wrote: I haven't done apr-iconv as Will Rowe had some reservations about that module. If someone who's more familiar wants to roll a tarball that's compatible with rc2 that'd be great. Doesn't matter - now that you've tagged apr-util-1.0.0 - we are locked into using that apr-iconv interface period for apr-iconv-1.0.0. All I'd suggested at this juncture is to add some notatation that the apr_iconv_ functions are private interfaces, e.g. @deprecated Private Interface! See the apr-util apr_xlate.h API. Sure. Works for me. Can we get some +1's on this? +1 from me. IMHO we can't release this tarball without moving to apr-1-config as mentioned in the apr pkgconfig thread. This allows us to have 0.9 and 1.0 installed side by side, e.g. if httpd and svn users are building both older and newer software. While they cannot be installed side by side, I'm -1 for release; once addressed I'm +1. I'm assuming that this is a reasonably trivial change that hopefully someone will make while I disappear off to work! david
Re: cvs commit: apr/strings apr_strings.c
Jim Jagielski wrote:
apr_snprintf(buf, 5, %3d , (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, );
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we check that the return value is =
the actual buffer size?
snprintf() is not as portable as we would like, so we need to use
apr_snprintf()
And apr_snprintf() tells us the same if len is 0.
so we'd have to call it twice...
I like Joe's suggestion of catching it in the test suite. If the API is ever
changed so that the caller specifies the length of their buffer, then there
will be an interesting case which apr_snprintf() could catch.
Re: cvs commit: apr configure.in config.layout
jorton 2004/06/30 06:16:54 Modified:.configure.in config.layout Log: * configure.in, config.layout: Add -version suffix to default installbuilddir directory. Revision ChangesPath 1.593 +1 -1 apr/configure.in This looks like a change that should go into 1.0...
Re: libtool pattern match fixes for build/get-version.sh
hi all...
Joe Schaefer wrote:
We've been using the build/get-version.sh script in
httpd-apreq-2. The following patch corrects the
libtool version string miscalculation (we let libtool
generate the shared library version for libapreq2, so
it's pretty well-tested).
The patch also includes a patch to correctly handle
multi-digit numbers (the original regexp will drop
all but the final digit due to the greediness of the
opening .* pattern.
did this slip through the cracks? I'm not good at reviewing this kind of
build thing, but it would help the httpd-apreq project out a bit if someone
who is could give it a glance and provide some feedback.
--Geoff
% diff -u apr/build/get-version.sh httpd-apreq-2/build/get-version.sh
--- apr/build/get-version.sh2002-09-10 09:11:20.0 +
+++ httpd-apreq-2/build/get-version.sh 2004-06-21 16:50:43.816189354 +
@@ -13,24 +13,24 @@
if test $# != 3; then
echo USAGE: $0 CMD INCLUDEDIR PREFIX
- echo where CMD is one of: all, major
+ echo where CMD is one of: all, major, libtool
exit 1
fi
-major_sed=/#define.*$3_MAJOR_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p
-minor_sed=/#define.*$3_MINOR_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p
-patch_sed=/#define.*$3_PATCH_VERSION/s/^.*\([0-9][0-9]*\).*$/\1/p
+major_sed=/#define.*$3_MAJOR_VERSION/s/^[^0-9]*\([0-9]*\).*$/\1/p
+minor_sed=/#define.*$3_MINOR_VERSION/s/^[^0-9]*\([0-9]*\).*$/\1/p
+patch_sed=/#define.*$3_PATCH_VERSION/s/^[^0-9]*\([0-9]*\).*$/\1/p
major=`sed -n $major_sed $2`
minor=`sed -n $minor_sed $2`
patch=`sed -n $patch_sed $2`
+ltmaj=`expr $major + $minor`
if test $1 = all; then
echo ${major}.${minor}.${patch}
elif test $1 = major; then
echo ${major}
elif test $1 = libtool; then
- # Yes, ${minor}:${patch}:${minor} is correct due to libtool idiocy.
- echo ${minor}:${patch}:${minor}
+ echo ${ltmaj}:${patch}:${minor}
else
echo ERROR: unknown version CMD ($1)
exit 1
Re: cvs commit: apr/strings apr_strings.c
At 08:17 AM 6/30/2004, Jeff Trawick wrote: I like Joe's suggestion of catching it in the test suite. If the API is ever changed so that the caller specifies the length of their buffer, then there will be an interesting case which apr_snprintf() could catch. Unfortunately, you would need to test the full range of possible inputs or you won't catch an edge case. One question, perhaps, is why we silently succeed while truncating the output string in apr_snprintf(). Obviously some snprintf's pass, some fail, so there must be some religious argument over 'proper' behavior. My personal philosophy, retval -1 for apr_snprintf() would tell the user we succeeded in filling their buffer, and then choked. They gave us the size of the buffer, so they should know how much was filled if they are happy with the truncated result Because the (new) flavor can never overflow (invoking apr_snprintf), I'd be happy ignoring the retval entirely. If the last position is non-alpha, the user knows something was borked. Either way, there isn't the risk of an overflow anymore. Bill
Re: 1.0 rc2 Tarballs
David Reid [EMAIL PROTECTED] writes: [...] Now, can people test them and we'll see if we get enough +1's ? I'm running debian-amd64, however I don't believe the problem below is platform-specific: % cd apr-1.0.rc2; ./configure make ... builds ok ... % make check (cd test make check) ... make[1]: Entering directory `/home/joe/tmp/apr-1.0.rc2/test' /bin/sh /home/joe/tmp/apr-1.0.rc2/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I../include -I./../include -o testlock.lo -c testlock.c touch testlock.lo testlock.c:66:22: test_apr.h: No such file or directory Once again, AFAICT the major version number appearing in the .so is not right: $ ls .libs libapr-1.a libapr-1.lai libapr-1.so.0 libapr-1.la libapr-1.so libapr-1.so.0.0.0 If you want the so's major number to be a 1, by applying the get-version.sh patch I posted last week you'll wind up with this: % ls .libs libapr-1.a libapr-1.lai libapr-1.so.1 libapr-1.la libapr-1.so libapr-1.so.1.0.0 -- Joe Schaefer
Re: apr pkgconfig use (apr.pc vs. apr-1.pc)
On Wed, 2004-06-30 at 04:56, Joe Orton wrote: Install apr-config as apr-$(APR_MAJOR_VERSION)-config ? Greg wrote remove rather than rename, though indeed, I guess renaming should work. Renaming is also fine.
Re: 1.0 rc2 Tarballs
On Wed, Jun 30, 2004 at 10:36:36AM -0400, Joe Schaefer wrote: David Reid [EMAIL PROTECTED] writes: [...] Now, can people test them and we'll see if we get enough +1's ? I'm running debian-amd64, however I don't believe the problem below is platform-specific: ... testlock.lo testlock.c:66:22: test_apr.h: No such file or directory testlock.c has been tagged at a really old version, I'm not sure why. The version in HEAD works. Once again, AFAICT the major version number appearing in the .so is not right: I'll follow up on this in the other separate thread. joe
Re: 1.0 rc2 Tarballs
Same problem on RH Enterprise edition ... yes it doesn't look like platform specific. Joe Schaefer wrote: "David Reid" [EMAIL PROTECTED] writes: [...] Now, can people test them and we'll see if we get enough +1's ? I'm running debian-amd64, however I don't believe the problem below is platform-specific: % cd apr-1.0.rc2; ./configure make ... builds ok ... % make check (cd test make check) ... make[1]: Entering directory `/home/joe/tmp/apr-1.0.rc2/test' /bin/sh /home/joe/tmp/apr-1.0.rc2/libtool --silent --mode=compile gcc -g -O2 -pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -I../include -I./../include -o testlock.lo -c testlock.c touch testlock.lo testlock.c:66:22: test_apr.h: No such file or directory Once again, AFAICT the major version number appearing in the .so is not right: $ ls .libs libapr-1.a libapr-1.lai libapr-1.so.0 libapr-1.la libapr-1.so libapr-1.so.0.0.0 If you want the so's major number to be a "1", by applying the get-version.sh patch I posted last week you'll wind up with this: % ls .libs libapr-1.a libapr-1.lai libapr-1.so.1 libapr-1.la libapr-1.so libapr-1.so.1.0.0
Re: apr-util RPM - I'm stuck
On Wed, Jun 23, 2004 at 06:46:07PM +0200, Graham Leggett wrote: Is the correct fix then to move the awk scripts from the source directory to the build directory? (When I looked last night the awk scripts seemed to live in apr/build already, unless you're referring to other scripts) I found a cleaner way to make this work (fingers crossed); there should be no hacks needed to make an RPM out of HEAD now for either apr or apr-util. joe
Re: 1.0 rc2 Tarballs
On Wed, Jun 30, 2004 at 10:36:36AM -0400, Joe Schaefer wrote: David Reid [EMAIL PROTECTED] writes: [...] Now, can people test them and we'll see if we get enough +1's ? I'm running debian-amd64, however I don't believe the problem below is platform-specific: ... testlock.lo testlock.c:66:22: test_apr.h: No such file or directory testlock.c has been tagged at a really old version, I'm not sure why. The version in HEAD works. Whoops! As one could say, bugger. Let me retag and update the tarballs... No reason for an RC3, just a revised RC2 I think... david
Re: apr-util RPM - I'm stuck
Joe Orton wrote: I found a cleaner way to make this work (fingers crossed); there should be no hacks needed to make an RPM out of HEAD now for either apr or apr-util. Ok - should I commit the RPM spec files setup I have so far (should not affect existing setups, it's the same code that creates the httpd spec file)? Regards, Graham --
Re: apr-util RPM - I'm stuck
On Wed, Jun 30, 2004 at 05:27:22PM +0200, Graham Leggett wrote: Joe Orton wrote: I found a cleaner way to make this work (fingers crossed); there should be no hacks needed to make an RPM out of HEAD now for either apr or apr-util. Ok - should I commit the RPM spec files setup I have so far (should not affect existing setups, it's the same code that creates the httpd spec file)? Can you post them for review first? joe
Re: apr-util RPM - I'm stuck
Joe Orton wrote:
Can you post them for review first?
The patch is to buildconf. It creates apr.spec from apr.spec.in on
platforms that support cut.
On other platforms, this code is ignored.
The apr.spec.in file is modified to include the version number from
apr_version.h. Whether the apr.spec.in file is bogus or not does not
affect buildconf.
This code was taken from the buildconf currently present inside httpd-2.0.
Regards,
Graham
--
? apr.spec
? build/rpm
Index: buildconf
===
RCS file: /home/cvs/apr/buildconf,v
retrieving revision 1.30
diff -u -r1.30 buildconf
--- buildconf 6 Jun 2004 21:19:19 - 1.30
+++ buildconf 30 Jun 2004 15:45:59 -
@@ -83,4 +83,20 @@
echo Generating 'make' outputs ...
build/gen-build.py make
+# Create RPM Spec file
+if [ -f `which cut` ]; then
+ echo rebuilding rpm spec file
+ ( REVISION=`build/get-version.sh all include/apr_version.h APR`
+VERSION=`echo $REVISION | cut -d- -s -f1`
+RELEASE=`echo $REVISION | cut -d- -s -f2`
+if [ x$VERSION = x ]; then
+ VERSION=$REVISION
+ RELEASE=1
+fi
+cat ./build/rpm/apr.spec.in | \
+sed -e s/APR_VERSION/$VERSION/ \
+-e s/APR_RELEASE/$RELEASE/ \
+ apr.spec )
+fi
+
exit 0
%define aprver 1
Summary: Apache Portable Runtime library
Name: apr
Version: APR_VERSION
Release: APR_RELEASE
License: Apache Software License
Group: System Environment/Libraries
URL: http://apr.apache.org/
Source0: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot
BuildPrereq: autoconf, libtool, doxygen
Conflicts: subversion 0.20.1-2
%description
The mission of the Apache Portable Runtime (APR) is to provide a
free library of C data structures and routines, forming a system
portability layer to as many operating systems as possible,
including Unices, MS Win32, BeOS and OS/2.
%package devel
Group: Development/Libraries
Summary: APR library development kit
Requires: apr = %{version}
Conflicts: subversion-devel 0.20.1-2
%description devel
This package provides the support files which can be used to
build applications using the APR library. The mission of the
Apache Portable Runtime (APR) is to provide a free library of
C data structures and routines.
%prep
%setup -q
%build
# regenerate configure script etc.
./buildconf
%configure \
--prefix=/usr \
--includedir=%{_includedir}/apr-%{aprver} \
--with-installbuilddir=%{_libdir}/apr/build \
--with-devrandom=/dev/urandom \
CC=gcc CXX=g++
make %{?_smp_mflags} make dox
%check
# Run non-interactive tests
%ifarch x86_64
# https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=97611
excludes=testlock
%endif
pushd test
make %{?_smp_mflags} testall CFLAGS=-fno-strict-aliasing
TZ=PST8PDT ./testall -v ${excludes+-x $excludes} || exit 1
popd
%install
rm -rf $RPM_BUILD_ROOT
make install DESTDIR=$RPM_BUILD_ROOT
# These are referenced by apr_rules.mk
for f in make_exports.awk make_var_export.awk apr_common.m4 find_apr.m4; do
install -m 644 build/${f} $RPM_BUILD_ROOT%{_libdir}/apr/build/${f}
done
install -m 755 build/config.sub $RPM_BUILD_ROOT%{_libdir}/apr/build/config.sub
install -m 755 build/mkdir.sh $RPM_BUILD_ROOT%{_libdir}/apr/build/mkdir.sh
install -m 755 build/install.sh $RPM_BUILD_ROOT%{_libdir}/apr/build/install.sh
install -m 755 build/gen-build.py
$RPM_BUILD_ROOT%{_libdir}/apr/build/gen-build.py
# Sanitize apr_rules.mk
sed -e /^apr_build/d \
-e 's|$(apr_builders)|%{_libdir}/apr/build|g' \
-e 's|$(apr_builddir)|%{_libdir}/apr/build|g' \
build/apr_rules.mk $RPM_BUILD_ROOT%{_libdir}/apr/build/apr_rules.mk
# Move docs to more convenient location
mv docs/dox/html html
# Unpackaged files:
rm -f $RPM_BUILD_ROOT%{_libdir}/apr.exp
%clean
rm -rf $RPM_BUILD_ROOT
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig
%files
%defattr(-,root,root,-)
%doc CHANGES LICENSE
%{_libdir}/libapr-%{aprver}.so.*
%files devel
%defattr(-,root,root,-)
%doc docs/APRDesign.html docs/canonical_filenames.html
%doc docs/incomplete_types docs/non_apr_programs
%doc --parents html
%{_bindir}/apr-config
%{_libdir}/libapr-%{aprver}.*a
%{_libdir}/libapr-%{aprver}.so
%dir %{_libdir}/apr
%dir %{_libdir}/apr/build
%{_libdir}/apr/build/*
%{_libdir}/pkgconfig/apr.pc
%dir %{_includedir}/apr-%{aprver}
%{_includedir}/apr-%{aprver}/*.h
%changelog
* Tue Jun 22 2004 Graham Leggett [EMAIL PROTECTED] 1.0.0-1
- update to support v1.0.0 of APR
* Tue Jun 15 2004 Elliot Lee [EMAIL PROTECTED]
- rebuilt
* Thu Jun 10 2004 Joe Orton [EMAIL PROTECTED] 0.9.4-15
- add support for setuid/setgid/sticky bits (André Malo)
- add apr_threadattr_{guardsize,stacksize}_set() (latter by Jeff Trawick)
* Mon Jun 7 2004 Joe Orton [EMAIL PROTECTED] 0.9.4-14
- enable posixsem and process-shared pthread mutex support, but
ensure that sysvsem remains the default mechanism
* Mon May 24 2004 Joe Orton [EMAIL PROTECTED] 0.9.4-13
- entirely remove 2Gb file size limit
1.0.0.rc2 tarballs now ready...
So, I fixed the incorrect tag and rerolled. The revised tarballs (correctly named to keep Joe happy this time) are being uploaded into the usual place, http://www.apache.org/~dreid/ as I write this. I'll delete the old tarballs to avoid confusion. Now, just to be clear, I believe that there's a -1 hanging over the release (from Will Rowe) until we have versioning on the apr(apu)-config file, so hopefully someone will fix that and then an rc3 will be required to ensure that everyone is happy. Given there will be an rc3 can people look at the libtool patch and see if it's worthwhile incorporating? The poster said that it would help out a using project which IMHO makes it worth a look. So, maybe an RC3 on Friday but if people could test this revised rc2 and let me know. I'm seeing a single failure on FreeBSD (teststr.c line 134) but am already running a bit late! david
Re: libtool pattern match fixes for build/get-version.sh
On Mon, Jun 21, 2004 at 01:02:58PM -0400, Joe Schaefer wrote: We've been using the build/get-version.sh script in httpd-apreq-2. The following patch corrects the libtool version string miscalculation (we let libtool generate the shared library version for libapreq2, so it's pretty well-tested). The patch also includes a patch to correctly handle multi-digit numbers (the original regexp will drop all but the final digit due to the greediness of the opening .* pattern. The sed fix is clearly good, thanks. The ltmaj fix is not necessary for APR, since APR embeds the major version in the library name to allow parallel installs of different major versions, so always passing CURRENT == AGE as the libtool interface versions is OK. I'm a little hesitant about gratuitously changing the soname just before a major release, and after 1.0 it will be too late. Is there a reason why you need the get-version.sh script included in APR to behave like this, rather than just using a local modification in the copy in the libapreq2 tree? Regards, joe
Re: libtool pattern match fixes for build/get-version.sh
--On Wednesday, June 30, 2004 5:02 PM +0100 Joe Orton [EMAIL PROTECTED] wrote: I'm a little hesitant about gratuitously changing the soname just before a major release, and after 1.0 it will be too late. Is there a reason why you need the get-version.sh script included in APR to behave like this, rather than just using a local modification in the copy in the libapreq2 tree? +1. Now is *not* the time to make goofy changes like this. -- justin
Re: 1.0 rc2 Tarballs
David Reid [EMAIL PROTECTED] writes: [...] Let me retag and update the tarballs... No reason for an RC3, just a revised RC2 I think... Also have a look at apr-util-1.0.rc2/test/testpass.c: it isn't a program, so you probably need HEAD for that also. -- Joe Schaefer
Re: 1.0.0.rc2 tarballs now ready...
On Wed, Jun 30, 2004 at 05:00:52PM +0100, David Reid wrote: So, I fixed the incorrect tag and rerolled. The revised tarballs (correctly named to keep Joe happy this time) are being uploaded into the usual place, http://www.apache.org/~dreid/ as I write this. I'll delete the old tarballs to avoid confusion. Now, just to be clear, I believe that there's a -1 hanging over the release (from Will Rowe) until we have versioning on the apr(apu)-config file, so hopefully someone will fix that and then an rc3 will be required to ensure that everyone is happy. Given there will be an rc3 can people look at the libtool patch and see if it's worthwhile incorporating? The poster said that it would help out a using project which IMHO makes it worth a look. So, maybe an RC3 on Friday but if people could test this revised rc2 and let me know. I'm seeing a single failure on FreeBSD (teststr.c line 134) but am already running a bit late! The apr_snprintf change is missing from the tarball, but its test is not: Fix apr_snprintf() to respect precision for small floating point numbers. PR: 29621 Submitted by: Artur Zaprzala zybi talex.pl Reviewed by: Jeff Trawick needs: cvs tag -r1.39 APR_1_0_RC2 strings/apr_snprintf.c joe
Re: libtool pattern match fixes for build/get-version.sh
Joe Orton [EMAIL PROTECTED] writes: [...] The ltmaj fix is not necessary for APR, since APR embeds the major version in the library name to allow parallel installs of different major versions, so always passing CURRENT == AGE as the libtool interface versions is OK. I'm a little hesitant about gratuitously changing the soname just before a major release, and after 1.0 it will be too late. No worries, it's a minor polish issue that allows the APR_DOTTED_VERSION to match the generated soname. I brought it up now because it wasn't an issue in the 0.9.X releases. If binary compatibility has been stable since apr started generating libapr-1.so.0.0.0, then changing the soname would be a bad idea. OTOH if it has broken recently, then bumping the number might be worth consideration. Is there a reason why you need the get-version.sh script included in APR to behave like this, rather than just using a local modification in the copy in the libapreq2 tree? No- libapreq2's dependency on apr is solely through apr-config. Whatever decision is made on the soname will not impact libapreq2. However, adjusting its name to apr-1-config will likely us avoid problems in the future (since we're tied to httpd-2.0's ABI). -- Joe Schaefer
Re: 1.0.0.rc2 tarballs now ready...
On Wed, Jun 30, 2004 at 05:00:52PM +0100, David Reid wrote: So, I fixed the incorrect tag and rerolled. The revised tarballs (correctly named to keep Joe happy this time) are being uploaded into the usual place, http://www.apache.org/~dreid/ as I write this. I'll delete the old tarballs to avoid confusion. Now, just to be clear, I believe that there's a -1 hanging over the release (from Will Rowe) until we have versioning on the apr(apu)-config file, so hopefully someone will fix that and then an rc3 will be required to ensure that everyone is happy. Given there will be an rc3 can people look at the libtool patch and see if it's worthwhile incorporating? The poster said that it would help out a using project which IMHO makes it worth a look. So, maybe an RC3 on Friday but if people could test this revised rc2 and let me know. I'm seeing a single failure on FreeBSD (teststr.c line 134) but am already running a bit late! The apr_snprintf change is missing from the tarball, but its test is not: Fix apr_snprintf() to respect precision for small floating point numbers. PR: 29621 Submitted by: Artur Zaprzala zybi talex.pl Reviewed by: Jeff Trawick Harrumph. I actually went through my tagging to ensure that fix had made it in! I even checked to make sure I had the correct revision number to tag. Guess brain to hand communication wasn't working at that moment! Oh well, RC3 will pick this up. As long as the (potential) veto has had a fix committed I'll re-roll on Friday when I get home (around 4pm UK time). david
Re: 1.0.0.rc2 tarballs now ready...
I am getting the following error when running CGIs on the current version of NetWare (6.5 sp2): (32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed I am working on tracking down the problem. JJ "David Reid" [EMAIL PROTECTED] 6/30/2004 10:00:52 AM So, I fixed the incorrect tag and rerolled. The revised tarballs (correctlynamed to keep Joe happy this time) are being uploaded into the usual place,http://www.apache.org/~dreid/ as I write this.I'll delete the old tarballs to avoid confusion.Now, just to be clear, I believe that there's a -1 hanging over the release(from Will Rowe) until we have versioning on the apr(apu)-config file, sohopefully someone will fix that and then an rc3 will be required to ensurethat everyone is happy. Given there will be an rc3 can people look at thelibtool patch and see if it's worthwhile incorporating? The poster said thatit would help out a using project which IMHO makes it worth a look.So, maybe an RC3 on Friday but if people could test this revised rc2 and letme know. I'm seeing a single failure on FreeBSD (teststr.c line 134) but amalready running a bit late!david
Re: 1.0.0.rc2 tarballs now ready...
Jean-Jacques Clar [EMAIL PROTECTED] writes: [...] Given there will be an rc3 can people look at the libtool patch and see if it's worthwhile incorporating? The poster said that it would help out a using project which IMHO makes it worth a look. Geoff may have misspoke about my libtool patch helping apreq. It doesn't- it really makes no difference to apreq at all. I submitted it here because I believed it to be an oversight during the 1.X changeover. However looking again over the versioning.html page on apr's site, the current naming scheme for 1.0.0 is already documented there, so changing the scheme now would be a mistake. -- Joe Schaefer
broken pipe (was:Re: 1.0.0.rc2 tarballs now ready...)
I am getting the following error when running CGIs on the current version of NetWare (6.5 sp2): (32)Broken pipe: ap_content_length_filter: apr_bucket_read() failed I am working on tracking down the problem. Changes done to mod_cgi.c, mod_include.(h c) back in August 22, 2003 are exposinga broken pipe problem on NetWare. mod_cgi.c had a great deal of change in r1.153. I am not sure what exactly is causing that problem. It is surfacingonly now because of recent changes in the pipe code of our own library. At this point I am highly suspicious thatthe problem is in our library, but it could also be in the http/apr code. We are trying to isolate the problem and will update the list with any new info. JJ
