Re: 1.0.0 RC4
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
--On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna [EMAIL PROTECTED] 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
On Tue, Jul 13, 2004 at 09:22:34PM -0700, Justin Erenkrantz wrote: --On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna [EMAIL PROTECTED] 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 - 1.67 +++ build/apr_hints.m4 14 Jul 2004 08:08:38 - @@ -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
--On Tuesday, July 13, 2004 8:32 PM -0700 Paul Querna [EMAIL PROTECTED] 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
Inexplicable crash in apr_thread_exit
I'm trying to understand a crash, but I can't seem to get enough
information from the debugger to understand it's cause. In one
function, a variable looks ok, but in a function called from there with
that variable as an argument, the variable has no value (0x00).
(gdb) bt
#0 apr_pool_destroy (pool=0x2885e18) at apr_pools.c:783
#1 0x0163a5ec in apr_thread_exit (thd=0x0, retval=42275328) at
thread.c:192
#2 0x01521f3c in connect_thread_main (thread=0x287dea0, arg=0x55ece0)
at jxta_rdv_service_client.c:2208
#3 0x900246e8 in _pthread_body ()
#2 0x01521f3c in connect_thread_main (thread=0x287dea0, arg=0x55ece0)
at jxta_rdv_service_client.c:2208
2208 apr_thread_exit(thread, JXTA_SUCCESS);
(gdb) print thread
$1 = (struct apr_thread_t *) 0x287dea0
(gdb) down
#1 0x0163a5ec in apr_thread_exit (thd=0x0, retval=42275328) at
thread.c:192
192 apr_pool_destroy(thd-pool);
(gdb) print thd
$2 = (apr_thread_t *) 0x0
The variables thread and thd should have the same value;
Code:
APR_DECLARE(apr_status_t) apr_thread_exit(apr_thread_t *thd,
apr_status_t retval)
{
thd-exitval = retval;
apr_pool_destroy(thd-pool);
pthread_exit(NULL);
return APR_SUCCESS;
}
but it doesn't crash until apr_pool_destroy (which I really don't
understand, if thd is 0x0) when parts of pool are accessed illegally.
BTW, this is one of those times that it would really make sense to use
the same name for the same kind of variable; in this case, changing
thd to thread. How much typing did thd really save?
Thanks,
--
Brent Gulanowski[EMAIL PROTECTED]
smime.p7s
Description: S/MIME cryptographic signature
Re: 1.0.0 RC4
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 [EMAIL PROTECTED]
Re: 1.0.0 RC4
--On Wednesday, July 14, 2004 9:11 AM +0100 Joe Orton [EMAIL PROTECTED] 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
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
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
--On Wednesday, July 14, 2004 4:15 PM +0100 Joe Orton [EMAIL PROTECTED] 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
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
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
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 [EMAIL PROTECTED] Bill
Re: [PATCH APR 1.0] crtime v.s. intime
Ping list - 12 days elapsed. No interest? Only comment was from Branko,
and not in response to this patch.
Since we've floated about this for a year with only a few interested parties
- I suppose it's time to kill the proposal and just document the inconsistency.
Attached are two patches, one introduces intime/crtime (I missed adding
the actual apr_time_t intime member in the last patch - this fixes it.)
The doc_fix patch just documents the deficiency. Let's pick one or the other.
Bill
At 03:06 PM 7/2/2004, William A. Rowe, Jr. wrote:
Here's the patch for those interested, which splits ctime into crtime
and intime.
An interesting side effect, neither crtime nor intime stay part of the
APR_FINFO_MIN set of information - one bit or the other would be
toggled.
Index: include/apr_file_info.h
===
RCS file: /home/cvs/apr/include/apr_file_info.h,v
retrieving revision 1.47
diff -u -r1.47 apr_file_info.h
--- include/apr_file_info.h 25 Jun 2004 15:28:42 - 1.47
+++ include/apr_file_info.h 14 Jul 2004 20:22:03 -
@@ -133,7 +133,7 @@
#define APR_FINFO_LINK 0x0001 /** Stat the link not the file itself if
it is a link */
#define APR_FINFO_MTIME 0x0010 /** Modification Time */
-#define APR_FINFO_CTIME 0x0020 /** Creation Time */
+#define APR_FINFO_CTIME 0x0020 /** Creation or inode-changed time */
#define APR_FINFO_ATIME 0x0040 /** Access Time */
#define APR_FINFO_SIZE 0x0100 /** Size of the file */
#define APR_FINFO_CSIZE 0x0200 /** Storage size consumed by the file */
@@ -191,7 +191,7 @@
apr_time_t atime;
/** The time the file was last modified */
apr_time_t mtime;
-/** The time the file was last changed */
+/** The time the file was created, or the inode was last changed */
apr_time_t ctime;
/** The pathname of the file (possibly unrooted) */
const char *fname;
Index: file_io/netware/filestat.c
===
RCS file: /home/cvs/apr/file_io/netware/filestat.c,v
retrieving revision 1.34
diff -u -r1.34 filestat.c
--- file_io/netware/filestat.c 29 Mar 2004 17:53:28 - 1.34
+++ file_io/netware/filestat.c 14 Jul 2004 20:13:39 -
@@ -55,8 +55,9 @@
static void fill_out_finfo(apr_finfo_t *finfo, struct stat *info,
apr_int32_t wanted)
{
-finfo-valid = APR_FINFO_MIN | APR_FINFO_IDENT | APR_FINFO_NLINK
-| APR_FINFO_OWNER | APR_FINFO_PROT;
+finfo-valid = APR_FINFO_MIN | APR_FINFO_INTIME
+ | APR_FINFO_IDENT | APR_FINFO_NLINK
+ | APR_FINFO_OWNER | APR_FINFO_PROT;
finfo-protection = apr_unix_mode2perms(info-st_mode);
finfo-filetype = filetype_from_mode(info-st_mode);
finfo-user = info-st_uid;
@@ -67,7 +68,8 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime.tv_sec);
apr_time_ansi_put(finfo-mtime, info-st_mtime.tv_sec);
-apr_time_ansi_put(finfo-ctime, info-st_ctime.tv_sec);
+/* XXX Is this intime (or actually cr time?) */
+apr_time_ansi_put(finfo-intime, info-st_ctime.tv_sec);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/os2/dir.c
===
RCS file: /home/cvs/apr/file_io/os2/dir.c,v
retrieving revision 1.36
diff -u -r1.36 dir.c
--- file_io/os2/dir.c 13 Feb 2004 09:38:24 - 1.36
+++ file_io/os2/dir.c 14 Jul 2004 20:13:39 -
@@ -101,12 +101,12 @@
thedir-entry.ftimeLastWrite);
apr_os2_time_to_apr_time(finfo-atime, thedir-entry.fdateLastAccess,
thedir-entry.ftimeLastAccess);
-apr_os2_time_to_apr_time(finfo-ctime, thedir-entry.fdateCreation,
+apr_os2_time_to_apr_time(finfo-crtime, thedir-entry.fdateCreation,
thedir-entry.ftimeCreation);
finfo-name = thedir-entry.achName;
finfo-valid = APR_FINFO_NAME | APR_FINFO_MTIME | APR_FINFO_ATIME |
-APR_FINFO_CTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
+APR_FINFO_CRTIME | APR_FINFO_TYPE | APR_FINFO_SIZE |
APR_FINFO_CSIZE;
return APR_SUCCESS;
Index: file_io/os2/filestat.c
===
RCS file: /home/cvs/apr/file_io/os2/filestat.c,v
retrieving revision 1.41
diff -u -r1.41 filestat.c
--- file_io/os2/filestat.c 22 May 2004 07:26:10 - 1.41
+++ file_io/os2/filestat.c 14 Jul 2004 20:13:39 -
@@ -42,11 +42,11 @@
fstatus-ftimeLastAccess );
apr_os2_time_to_apr_time(finfo-mtime, fstatus-fdateLastWrite,
fstatus-ftimeLastWrite );
-apr_os2_time_to_apr_time(finfo-ctime, fstatus-fdateCreation,
+
Re: 1.0.0 RC4 (apr-config - apr-1-config)
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: [PATCH APR 1.0] crtime v.s. intime
On Wed, Jul 14, 2004 at 03:21:33PM -0500, William A. Rowe, Jr. wrote: Ping list - 12 days elapsed. No interest? Only comment was from Branko, and not in response to this patch. Since we've floated about this for a year with only a few interested parties - I suppose it's time to kill the proposal and just document the inconsistency. Attached are two patches, one introduces intime/crtime (I missed adding the actual apr_time_t intime member in the last patch - this fixes it.) The doc_fix patch just documents the deficiency. Let's pick one or the other. Bill Splitting ctime does improve representational correctness, but as I think about it, I doubt it helps folks write more portable programs. It does not presently make more information available; each OS either fills intime or fills crtime. Library users will need to modify their code to cope with this change, albeit trivially, and I'm not seeing what they will then have the new ability to do. For better or worse, ctime just isn't very useful. On Windows, it lets you smile about the fact that you have your very own file from 1988. On Unix, it's a (weak) auditing tool; one can change a file's mtime to anything, but doing so advances ctime, and one cannot arbitrarily set ctime. As such, assuming the integrity of the kernel and the filesystem backing store, a file will not have changed since the later of its ctime or mtime. It might be useful to define e.g. APR_CTIME_IS_CREATE_TIME on systems where that is the case. This would not prompt changes to programs that use ctime casually, and programs that do care could test for that and behave accordingly. I would (unofficially, of course) vote for the comments patch. Should APR ever support an OS that makes both crtime and intime available, I think your change would be excellent. If such an OS is mainstream now and we just don't support it yet, then your proposal may be good to incorporate so APR can support both values later without such an API change. Hopefully that is of some value to the discussion.
Re: 1.0.0 RC4 (apr-config - apr-1-config)
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 APR 1.0] crtime v.s. intime
On Wed, Jul 14, 2004 at 02:46:41PM -0700, Noah Misch wrote: Attached are two patches, one introduces intime/crtime (I missed adding the actual apr_time_t intime member in the last patch - this fixes it.) The doc_fix patch just documents the deficiency. Let's pick one or the other. Bill I would (unofficially, of course) vote for the comments patch. Should APR ever support an OS that makes both crtime and intime available, I think your change would be excellent. If such an OS is mainstream now and we just don't support it yet, then your proposal may be good to incorporate so APR can support both values later without such an API change. Well, there is such an OS discreetly marketed as FreeBSD. Let's implement your proposal so we can populate both fields there. Other BSDs supporting UFS2 may also expose st_birthtime.
Re: Inexplicable crash in apr_thread_exit
On Wed, Jul 14, 2004 at 08:42:33AM -0400, Brent Gulanowski wrote: I'm trying to understand a crash, but I can't seem to get enough information from the debugger to understand it's cause. In one function, a variable looks ok, but in a function called from there with that variable as an argument, the variable has no value (0x00). Could be any random memory corruption issue or pool lifetime problems as far as I can tell. Building with --enable-pool-debug and then running your program under electric fence is a good way to track these down. (or enabling libc malloc checking e.g. export MALLOC_CHECK_=2 with glibc) joe
Re: 1.0.0 RC4 (apr-config - apr-1-config)
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
