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: 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: 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: 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: 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: 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: 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
