Re: Autoconf breakage
--On Saturday, August 7, 2004 1:44 PM +1000 Brian Havard [EMAIL PROTECTED] wrote: The 2.13 macro is actually AC_MSG_WARN but when I tried using that it still failed while it was contained in the m4_if. Moving the line out of the m4_if, having the $0 in there seems to cause some kind of infinite recursion (process dies eventually from lack of memory). Well, m4_if isn't even supported on autoconf-2.13 and AC_MSG_WARN is for configure-time warnings, not autoconf-time warnings - which is what we wanted this to be. Regardless, please try HEAD. I will also note that libtool-1.5 and higher *require* autoconf-2.50 or higher. So, I would expect that we should drop autoconf-2.13 support sometime in the near future via AC_PREREQ(2.50). (In fact for releases, autoconf-2.13 is certainly way too buggy.) -- justin
Re: Autoconf breakage
Justin Erenkrantz wrote: --On Saturday, August 7, 2004 1:44 PM +1000 Brian Havard [EMAIL PROTECTED] wrote: The 2.13 macro is actually AC_MSG_WARN but when I tried using that it still failed while it was contained in the m4_if. Moving the line out of the m4_if, having the $0 in there seems to cause some kind of infinite recursion (process dies eventually from lack of memory). Well, m4_if isn't even supported on autoconf-2.13 and AC_MSG_WARN is for configure-time warnings, not autoconf-time warnings - which is what we wanted this to be. Regardless, please try HEAD. I will also note that libtool-1.5 and higher *require* autoconf-2.50 or higher. So, I would expect that we should drop autoconf-2.13 support sometime in the near future via AC_PREREQ(2.50). (In fact for releases, autoconf-2.13 is certainly way too buggy.) -- The releases have been rolled with 2.59. david
RC5
So, apart from the complaints about apr-util, are people happy that apr RC5 is OK? Are those who wanted the ldap code yanked now happy that it can be added back in? david
Re: RC5
--On Monday, August 9, 2004 12:36 PM +0100 David Reid [EMAIL PROTECTED] wrote: So, apart from the complaints about apr-util, are people happy that apr RC5 is OK? Releasing 1.0 with the known fact that autoconf-2.13 doesn't work with find_apr.m4 seems fine by me. We can release the latest find_apr.m4 in 1.0.1. Probably should document as such, or even point people at the patch - but users of the tarball won't likely be running buildconf. [If you wanted, you could include the new find_apr.m4 in 1.0 - your call.] My only concern is that apr-util still isn't 'fixed' wrt apu-config. I don't know if I'll have time to port those changes over soon. Perhaps we can go make APR 1.0 gold and then turn our focus on wrapping up APR-util (and APR-iconv)? -- justin
Re: RC5
Justin Erenkrantz wrote: --On Monday, August 9, 2004 12:36 PM +0100 David Reid [EMAIL PROTECTED] wrote: So, apart from the complaints about apr-util, are people happy that apr RC5 is OK? Releasing 1.0 with the known fact that autoconf-2.13 doesn't work with find_apr.m4 seems fine by me. We can release the latest find_apr.m4 in 1.0.1. Probably should document as such, or even point people at the patch - but users of the tarball won't likely be running buildconf. [If you wanted, you could include the new find_apr.m4 in 1.0 - your call.] OK. Which version is the one I should be including? My only concern is that apr-util still isn't 'fixed' wrt apu-config. I don't know if I'll have time to port those changes over soon. Well, the way things are going I'd suggest that getting those changes into apr-util should be a priority. I'd look but haven't been too involved with it all. Perhaps we can go make APR 1.0 gold and then turn our focus on wrapping up APR-util (and APR-iconv)? -- justin I debated that, but to be honest once we release 1.0.0 any momentum we have (what very little there remains) will dissipate very quickly - so let's go for all on the same day. Can we please have some folks looking at this stuff?? david
Re: RC5
--On Monday, August 9, 2004 5:46 PM +0100 David Reid [EMAIL PROTECTED] wrote: patch - but users of the tarball won't likely be running buildconf. [If you wanted, you could include the new find_apr.m4 in 1.0 - your call.] OK. Which version is the one I should be including? I *believe* r1.16 of build/find_apr.m4 should be okay. However, I'd like to see some other people verify that it works now. (It worked here with autoconf 2.13.) Well, the way things are going I'd suggest that getting those changes into apr-util should be a priority. I'd look but haven't been too involved with it all. I'll *try* to take a look later today... I debated that, but to be honest once we release 1.0.0 any momentum we have (what very little there remains) will dissipate very quickly - so let's go for all on the same day. Understood. -- justin
Re: RC5
David Reid wrote: So, apart from the complaints about apr-util, are people happy that apr RC5 is OK? Are those who wanted the ldap code yanked now happy that it can be added back in? david Here is what I'm getting trying to compile the latest HEAD on WIN32: Creating apr_ldap.h from apr_ldap.hw Compiling... apr_ldap_url.c ldap\apr_ldap_url.c(286) : warning C4013: 'apr_pstrdup' undefined; assuming extern returning int ldap\apr_ldap_url.c(672) : warning C4013: 'apr_strtok' undefined; assuming extern returning int apr_ldap_init.c ldap\apr_ldap_init.c(199) : warning C4090: 'function' : different 'const' qualifiers ldap\apr_ldap_init.c(222) : warning C4013: 'const_cast' undefined; assuming extern returning int ldap\apr_ldap_init.c(222) : error C2065: 'ldc' : undeclared identifier ldap\apr_ldap_init.c(222) : error C2223: left of '-host' must point to struct/union ldap\apr_ldap_init.c(222) : warning C4047: 'function' : 'PCHAR' differs in levels of indirection from 'int' ldap\apr_ldap_init.c(222) : error C2223: left of '-port' must point to struct/union ldap\apr_ldap_init.c(222) : error C2198: 'ldap_sslinit' : too few arguments for call through pointer-to-function So, if the latest ldap sources are going to be in the 1.0, then they need some fixes. Regards, MT. smime.p7s Description: S/MIME Cryptographic Signature
1.0
Hi, Perhaps im way off on this and please do correct me if i am wrong. Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. Not only code responsible for condvars under Win32 lacks any error checking whatsoever, there are also races, stuff which (to the best of my knowlege) results in upredictable behavior, so people using it will be bitten.. hard. -- mailto:[EMAIL PROTECTED]
Re: 1.0
Second that. The Win32 conditional problem was not new. I reported it and submited a patch back on Oct 28, 2003. Someone was looking at it (forgot the name), but never did check in a fix... Along the way, someone else ran into it and filed a report in bugzilla (id# 27654). Still no fix. I have given up waiting. For consolation, there isn't any deadlocks if I use only the broadcast() primitive. -cktan On Aug 10, 2004, at 12:57 AM, malc wrote: Hi, Perhaps im way off on this and please do correct me if i am wrong. Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. Not only code responsible for condvars under Win32 lacks any error checking whatsoever, there are also races, stuff which (to the best of my knowlege) results in upredictable behavior, so people using it will be bitten.. hard. -- mailto:[EMAIL PROTECTED]
Re: 1.0
Hi! On Mon, Aug 09, 2004 at 08:57:09PM +0400, malc wrote: Perhaps im way off on this and please do correct me if i am wrong. Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. Not only code responsible for condvars under Win32 lacks any error checking whatsoever, there are also races, stuff which (to the best of my knowlege) results in upredictable behavior, so people using it will be bitten.. hard. Threads are broken on win32 too (race condition in apr_thread_join and apr_thread_exit). /fjoe
Re: 1.0
On Mon, 9 Aug 2004, Justin Erenkrantz wrote: --On Monday, August 9, 2004 8:57 PM +0400 malc [EMAIL PROTECTED] wrote: Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. The number of Win32 developers who are knowledgeable about this area are fairly small, so any patches you may have are certainly welcomed. However, I will point out that it's probably been that way for years without anyone caring enough to fix it. I don't know a thing about Win32, so I'm of no help. And, suspect that to be the case for the majority of APR developers. I also doubt it's a problem in the API - so fixes to the Win32 condition variables can be done in APR 1.0.1 if someone steps up and fixes it. But, a 1.0 showstopper? I say no. But, adding a warning to the 1.0 release notes sounds fine to me. -- justin API is fine. As Max Khon pointed out there are other problems in Win32 threading, so i belive (big)warning would be a way to go. Plus perhaps a mention of win32 pthreads which are immune to these. After all APR threading API is based on Pthreads so people can convert later. -- mailto:[EMAIL PROTECTED]
Re: 1.0
malc, is there anything that can be done in our apr/test/ tree to validate the correct behavior, and tickle these bugs? This would obviously help validate the patches you propose, and possibly pick up such bugs in other condition variable implementations. The emphasis for 1.0.0 is API-complete. It won't mean zarro boogs. It will mean that as folks develop for APR 1.0 - the api won't shift beneath their feet from subversion to subversion, and it will remain backwards compatible from minor to minor version. In fact, for users who build APR-based apps, things will only get better (till 2.0 really improves things by a leap - but also will require the developers to make adjustments for the API - all at once.) I hope to find cycles this week to review the patches (don't let that stop anyone else of course.) A test case would obviously help, alot. Bill At 11:57 AM 8/9/2004, malc wrote: Hi, Perhaps im way off on this and please do correct me if i am wrong. Condition variables on Win32 are broken, if you are going to label APR with 1.0 mark and release it right now, without mentioning this fact in big red letters, this would essentially be equal to releasing a trojan horse - a free, attractive, portable thing with a stamp of greatness (Apache) in its name, but deadly. Not only code responsible for condvars under Win32 lacks any error checking whatsoever, there are also races, stuff which (to the best of my knowlege) results in upredictable behavior, so people using it will be bitten.. hard. -- mailto:[EMAIL PROTECTED]
Re: RC5
Justin Erenkrantz wrote: My only concern is that apr-util still isn't 'fixed' wrt apu-config. I don't know if I'll have time to port those changes over soon. I've already posted a patch! Max.
Re: 1.0
On Mon, 9 Aug 2004, William A. Rowe, Jr. wrote: malc, is there anything that can be done in our apr/test/ tree to validate the correct behavior, and tickle these bugs? This would obviously help validate the patches you propose, and possibly pick up such bugs in other condition variable implementations. No, but i would guess taking some tests from GLIBC and/or Win32 Pthreads would do, as APIs are quite similar. As for patches, current condition variable code is broken beyond repair, the whole aproach can't possibly work. There is at least one algorithm that does work and thats the one in Win32 Pthreads. I do not have enough expertise in this field to contribute any patches tests, i'm not even a Win32 coder. The emphasis for 1.0.0 is API-complete. It won't mean zarro boogs. It will mean that as folks develop for APR 1.0 - the api won't shift beneath their feet from subversion to subversion, and it will remain backwards compatible from minor to minor version. In fact, for users who build APR-based apps, things will only get better (till 2.0 really improves things by a leap - but also will require the developers to make adjustments for the API - all at once.) I wouldn't take my own word on it, but to me it looks like API is OK. I hope to find cycles this week to review the patches (don't let that stop anyone else of course.) A test case would obviously help, alot. -- mailto:[EMAIL PROTECTED]
Re: RC5
--On Monday, August 9, 2004 8:34 PM +0100 Max Bowsher [EMAIL PROTECTED] wrote: Justin Erenkrantz wrote: My only concern is that apr-util still isn't 'fixed' wrt apu-config. I don't know if I'll have time to port those changes over soon. I've already posted a patch! Oh, wow, you did. ;-) I'll take a look tonight at it then. Thanks. -- justin
Re: RC5
David Reid wrote: Are those who wanted the ldap code yanked now happy that it can be added back in? The majority of the fooness on the LDAP stuff was caused by the attempt to support the now archaic LDAP v2.0 C SDK, using macros. All the macros are now gone. Please speak up if there is anything else with the API that must not go out the door. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: 1.0
The chances that I have time to look at this are slim to none currently. My time is currently being swallowed by my job and my real life. Ryan On Mon, 09 Aug 2004 14:52:27 -0500, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: At 02:46 PM 8/9/2004, malc wrote: No, but i would guess taking some tests from GLIBC and/or Win32 Pthreads would do, as APIs are quite similar. As for patches, current condition variable code is broken beyond repair, the whole aproach can't possibly work. There is at least one algorithm that does work and thats the one in Win32 Pthreads. I do not have enough expertise in this field to contribute any patches tests, i'm not even a Win32 coder. Unfortunately, since everything you just mentioned is GPL, afaik, it's worthless to us. I'll review from a logical perspective. Threads and the proposed threading patch I grok (and accept :), while condition variables I'm less familiar with. Perhaps Bannert, Bloom and some other condition variable gurus will pipe up. Bill -- Ryan Bloom [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
