APR 1.4.x, 1.0.x on Snow Leopard
I'm still not having much luck with apr 1.4.x or 1.0.x on Snow Leopard. Just curious if my problems are unique? Since 1.4.x failed, and Snow Leopard's installed apr is called libapr-1.0.3.5.dylib, I also tried apr-1.0.x. On 1.4.x, buildconf fails; on 1.0.x; configure fails, so in both cases, I don't get far enough to even apply apple's patch for include/apr.h. include/apr.h. [08:35:01]poir...@slappy:~/apache/apr-1.4.x$ ./buildconf buildconf: checking installation... buildconf: python version 2.6.1 (ok) buildconf: autoconf version 2.61 (ok) buildconf: libtool version 2.2.4 (ok) Copying libtool helper files ... $_prefix/share/aclocal/libtool.m4 not found [08:35:12]poir...@slappy:~/apache/apr-1.4.x$ printenv PATH /bin:/usr/bin ... check out 1.0.x ... buildconf succeeds ... run configure ... checking for minix/config.h... no checking whether system uses EBCDIC... no performing libtool configuration... ./configure: line 9381: syntax error near unexpected token `lt_decl_varnames,' ./configure: line 9381: `lt_if_append_uniq(lt_decl_varnames, SED, , ,' [08:39:36]poir...@slappy:~/apache/apr-1.0.x$
Re: APR 1.4.x, 1.0.x on Snow Leopard
You have the latest Xcode, right? BTW: You may need to install external versions of libtool and the auto* suite; I use MacPorts. On Oct 12, 2009, at 8:43 AM, Dan Poirier wrote: I'm still not having much luck with apr 1.4.x or 1.0.x on Snow Leopard. Just curious if my problems are unique? Since 1.4.x failed, and Snow Leopard's installed apr is called libapr-1.0.3.5.dylib, I also tried apr-1.0.x. On 1.4.x, buildconf fails; on 1.0.x; configure fails, so in both cases, I don't get far enough to even apply apple's patch for include/apr.h. include/apr.h. [08:35:01]poir...@slappy:~/apache/apr-1.4.x$ ./buildconf buildconf: checking installation... buildconf: python version 2.6.1 (ok) buildconf: autoconf version 2.61 (ok) buildconf: libtool version 2.2.4 (ok) Copying libtool helper files ... $_prefix/share/aclocal/libtool.m4 not found [08:35:12]poir...@slappy:~/apache/apr-1.4.x$ printenv PATH /bin:/usr/bin ... check out 1.0.x ... buildconf succeeds ... run configure ... checking for minix/config.h... no checking whether system uses EBCDIC... no performing libtool configuration... ./configure: line 9381: syntax error near unexpected token `lt_decl_varnames,' ./configure: line 9381: `lt_if_append_uniq(lt_decl_varnames, SED, , ,' [08:39:36]poir...@slappy:~/apache/apr-1.0.x$
Re: APR 1.4.x, 1.0.x on Snow Leopard
Jim Jagielski j...@jagunet.com writes: You have the latest Xcode, right? BTW: You may need to install external versions of libtool and the auto* suite; I use MacPorts. I was running with the XCode that was current when Snow Leopard came out. I assumed Apple was building apr httpd with the tools they ship with Snow Leopard. Maybe that was my mistake :-) There's a slightly newer XCode (3.2.1, Oct. 8, 2009) available that I can try. Then I'll put Macports back on my PATH and see what that does. -- Dan Poirier poir...@pobox.com
Re: svn commit: r209046 - /apr/apr/branches/1.0.x/file_io/os2/open.c
On Tue, 05 Jul 2005 11:15:51 -0500, William A. Rowe, Jr. wrote: I'm not asking about Brian's patch, but how we are maintaining 1.0.x/1.1.x branches... Can we declare these 'dead'? For all intents and purposes, anyone building 1.2.x has an ABI compatible flavor that can be substituted for a 1.0.x or 1.1.x version, right? Good question. I'm not really clear on what the state of the different branches is. I'm just committing all the way back to 0.9.x to make sure the next httpd-2.0.x gets these bug fixes. Bill At 04:29 AM 7/4/2005, [EMAIL PROTECTED] wrote: Author: bjh Date: Mon Jul 4 02:29:09 2005 New Revision: 209046 URL: http://svn.apache.org/viewcvs?rev=209046view=rev Log: Bug #33844: OS/2: file opened with APR_CREATE would be truncated if APR_APPEND wasn't also given. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | --
Re: svn commit: r209046 - /apr/apr/branches/1.0.x/file_io/os2/open.c
On 7/6/05, Brian Havard [EMAIL PROTECTED] wrote: On Tue, 05 Jul 2005 11:15:51 -0500, William A. Rowe, Jr. wrote: I'm not asking about Brian's patch, but how we are maintaining 1.0.x/1.1.x branches... Can we declare these 'dead'? For all intents and purposes, anyone building 1.2.x has an ABI compatible flavor that can be substituted for a 1.0.x or 1.1.x version, right? Good question. I'm not really clear on what the state of the different branches is. I'm just committing all the way back to 0.9.x to make sure the next httpd-2.0.x gets these bug fixes. I'm fuzzy when it comes to practical matters, such as who (if anybody) is the benificiary of those other branches. Aren't those theoretical beneficiaries better off in the long run if we concentrate our efforts on a fewer number of branches? (But we have to have a versioning policy that allows the fewer number of branches without slowing down the implementation of new features unnecessarily.)
Re: svn commit: r209046 - /apr/apr/branches/1.0.x/file_io/os2/open.c
On Wed, Jul 06, 2005 at 09:17:46AM -0400, Jeff Trawick wrote: On 7/6/05, Brian Havard [EMAIL PROTECTED] wrote: On Tue, 05 Jul 2005 11:15:51 -0500, William A. Rowe, Jr. wrote: I'm not asking about Brian's patch, but how we are maintaining 1.0.x/1.1.x branches... Can we declare these 'dead'? For all intents and purposes, anyone building 1.2.x has an ABI compatible flavor that can be substituted for a 1.0.x or 1.1.x version, right? Good question. I'm not really clear on what the state of the different branches is. I'm just committing all the way back to 0.9.x to make sure the next httpd-2.0.x gets these bug fixes. I'm fuzzy when it comes to practical matters, such as who (if anybody) is the benificiary of those other branches. Aren't those theoretical beneficiaries better off in the long run if we concentrate our efforts on a fewer number of branches? (But we have to have a versioning policy that allows the fewer number of branches without slowing down the implementation of new features unnecessarily.) Maintaining simple fixes on a stable 1.1.x branch is useful since it means 1.1.x patch releases can be released on a whim regardless of the state of the trunk. I share the general apathy about the the 1.0.x branch. joe
Re: svn commit: r209046 - /apr/apr/branches/1.0.x/file_io/os2/open.c
I'm not asking about Brian's patch, but how we are maintaining 1.0.x/1.1.x branches... Can we declare these 'dead'? For all intents and purposes, anyone building 1.2.x has an ABI compatible flavor that can be substituted for a 1.0.x or 1.1.x version, right? Bill At 04:29 AM 7/4/2005, [EMAIL PROTECTED] wrote: Author: bjh Date: Mon Jul 4 02:29:09 2005 New Revision: 209046 URL: http://svn.apache.org/viewcvs?rev=209046view=rev Log: Bug #33844: OS/2: file opened with APR_CREATE would be truncated if APR_APPEND wasn't also given.
Re: apr-iconv 1.0
At 03:06 PM 4/6/2005, Curt Arnold wrote: The issues that I ran into: 1. apr_iconv dereferences inbytes_left without checking for NULL From the doc comments from apr_xlate_conv_buffer: If the final call is made as suggested, apr_iconv will case a null pointer exception. GNU iconv does not. I'll look. My concern is that this suggested doc change is part of a gnu libiconv-ism, which would break on FreeBSD. But I need to look. 2. apr_iconv does not have a WCHAR_T encoding. Isn't wchar_t the preference, from ANSI/C99 headers? 3. apr_xlate_open(convset, APR_LOCALE_CHARSET, ...) fails for common code pages (like 1252) on Windows This could be an artifact of my hacking. When this is attempted on my machine, the code determines the current code page (in my case 1252, Western European) and creates a corresponding encoding name like Cp1252. However, the corresponding encoding module is called windows-1252 not Cp1252. I can look. Bill
Re: apr-iconv 1.0
On Apr 7, 2005, at 10:54 AM, William A. Rowe, Jr. wrote: At 03:06 PM 4/6/2005, Curt Arnold wrote: The issues that I ran into: 1. apr_iconv dereferences inbytes_left without checking for NULL From the doc comments from apr_xlate_conv_buffer: If the final call is made as suggested, apr_iconv will case a null pointer exception. GNU iconv does not. I'll look. My concern is that this suggested doc change is part of a gnu libiconv-ism, which would break on FreeBSD. But I need to look. I wasn't suggesting a doc change, the doc is right and doing the final call to apr_xlate(conv, NULL, NULL) is the proper thing to do though it is only essential for some fairly obscure encodings. However, if you do the right thing and apr_xlate is using apr_iconv, it will fault. 2. apr_iconv does not have a WCHAR_T encoding. Isn't wchar_t the preference, from ANSI/C99 headers? The encoding and width of the wchar_t type is platform-dependent. GNU iconv has an encoding named WCHAR_T that can be used to convert, for example, from a wchar_t* to some other encoding. Without an WCHAR_T encoding, my code needs to know that wchar_t* on Win32 is UTF-16LE, UCS-4 on some other platform, etc and use the appropriate encoding name. 3. apr_xlate_open(convset, APR_LOCALE_CHARSET, ...) fails for common code pages (like 1252) on Windows This could be an artifact of my hacking. When this is attempted on my machine, the code determines the current code page (in my case 1252, Western European) and creates a corresponding encoding name like Cp1252. However, the corresponding encoding module is called windows-1252 not Cp1252. If you are really interested in tracking these down, I can write the test cases. However just the number of issues I was immediately running into was enough to make me rethink my plan on using apr-xlate for encoding services on all platforms.
Re: apr-iconv 1.0
All my previous discussion was speculative on apr-iconv's behavior. I was in the process of integrating use of apr_xlate to support specifying the encoding of log files but had not gotten to the point of testing at the time of the discussion. I have ran into several issues when using apr_xlate delegating to (a hacked) apr-iconv which I did not encounter when delegating to iconv. I don't believe the issues are related to my hacking of the load process, but that is always a possibility. At this point, my plans are to use Win32 API calls to support a small set of encodings on Windows and apr_xlate on other platforms. The issues that I ran into: 1. apr_iconv dereferences inbytes_left without checking for NULL From the doc comments from apr_xlate_conv_buffer: * To correctly terminate the output buffer for some multi-byte * character set encodings, a final call must be made to this function * after the complete input string has been converted, passing * the inbuf and inbytes_left parameters as NULL. (Note that this * mode only works from version 1.1.0 onwards) If the final call is made as suggested, apr_iconv will case a null pointer exception. GNU iconv does not. 2. apr_iconv does not have a WCHAR_T encoding. 3. apr_xlate_open(convset, APR_LOCALE_CHARSET, ...) fails for common code pages (like 1252) on Windows This could be an artifact of my hacking. When this is attempted on my machine, the code determines the current code page (in my case 1252, Western European) and creates a corresponding encoding name like Cp1252. However, the corresponding encoding module is called windows-1252 not Cp1252. The last two may be artifacts of my hacking. I didn't see any code that appeared to alias Cp1252 or WCHAR_T to an available encoding, but maybe I missed something. However, it was enough to shake any confidence I had in the approach I was using.
Re: apr-iconv 1.0
What are the licensing or technical issues of using the X-licensed ICU4C (http://ibm.com/software/globalization/icu) to implement apr_xlate on platforms that don't have a native iconv?
Re: apr-iconv 1.0
At 06:11 PM 3/30/2005, Curt Arnold wrote: What are the licensing or technical issues of using the X-licensed ICU4C (http://ibm.com/software/globalization/icu) to implement apr_xlate on platforms that don't have a native iconv? It's been 2 years since I examined the option. IIRC it's c++ code, and is akin to calling out the NY Mets when your son's little league team looses its pitcher. Other than that, I don't know there is any licensing issue or I would not have even grabbed the download back in the day. Bill
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: FWIW - who else in this community wants to participate if such an ASL/BSD licensed iconv project grew up around the most current code for iconv? Well, I'm interested if the final product will not depend on a hundred or so separate .dll's for each and every charset, and if apr_util will not depend on apr_iconv. Also I think we should consider using MultiByteToWideChar/WideCharToMultiByte on windows as an option to apr_xlate if iconv is not present. Regards, Mladen.
Re: apr-iconv 1.0
At 12:23 AM 3/31/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: FWIW - who else in this community wants to participate if such an ASL/BSD licensed iconv project grew up around the most current code for iconv? Well, I'm interested if the final product will not depend on a hundred or so separate .dll's for each and every charset, and if apr_util will not depend on apr_iconv. I'd see that as advantage as well. I understand loadable modules for complex translations, but not for tables. Also I think we should consider using MultiByteToWideChar/WideCharToMultiByte on windows as an option to apr_xlate if iconv is not present. See my post on this very point. The API does not lend itself whatsoever to streaming data. Most every APR application is dealing with streamed text so this isn't really a useful option.
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: Well, I'm interested if the final product will not depend on a hundred or so separate .dll's for each and every charset, and if apr_util will not depend on apr_iconv. I'd see that as advantage as well. I understand loadable modules for complex translations, but not for tables. I would like that we first resolve the static linking of apr-iconv to apr-utils, and using apr_dso_* for apr_iconv functionality. For me that is the major issue. Other is that reimplementing either Konstantin's iconv 2.x as part of apr_iconv would lead to the same problems. Either we will build something of our own, and take responsibility for that, or we will build a wrapper against what ever native iconv implementation there is. Having duality is IMO a bad thing. Also I think we should consider using MultiByteToWideChar/WideCharToMultiByte on windows as an option to apr_xlate if iconv is not present. See my post on this very point. The API does not lend itself whatsoever to streaming data. Most every APR application is dealing with streamed text so this isn't really a useful option. I'm sure we can think of something, but if you say that we can not use native WIN32, then we could at least offer the option to use gnu-iconv for win32 builds as well, or any other iconv-api library. Like said, I think that we should either build our own implementation of iconv functionality, or just build a wrapper over existing one. So, I see the future of apr-iconv as ASF implementation of iconv, with iconv abstraction layer moved to apr-utils, that will use apr-iconv, as just one of the flavors of iconv api. Regards, Mladen.
Re: apr-iconv 1.0
On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote: William A. Rowe, Jr. wrote: Well, I'm interested if the final product will not depend on a hundred or so separate .dll's for each and every charset, and if apr_util will not depend on apr_iconv. I'd see that as advantage as well. I understand loadable modules for complex translations, but not for tables. I would like that we first resolve the static linking of apr-iconv to apr-utils, and using apr_dso_* for apr_iconv functionality. For me that is the major issue. For log4cxx, I've replaced the module loading code so that all the encodings are present within liblog4cxx.so and/or log4cxx.dll. To do this, I included the module definitions inside C++ namespace blocks to prevent symbol collision. Obviously that is not an appropriate approach for apr-iconv itself, but it seems likely that you could do a similar thing using preprocessor macros instead of C++ namespaces. I'm sure we can think of something, but if you say that we can not use native WIN32, then we could at least offer the option to use gnu-iconv for win32 builds as well, or any other iconv-api library. How could gnu-iconv be an option for an Apache project due to the license conflicts? There don't seem to be any appropriate iconv implementations for Windows. Like said, I think that we should either build our own implementation of iconv functionality, or just build a wrapper over existing one. So, I see the future of apr-iconv as ASF implementation of iconv, with iconv abstraction layer moved to apr-utils, that will use apr-iconv, as just one of the flavors of iconv api. I'm not sure how that is different that the current state. Currently, apr_xlate in apr-util will use a native iconv implementation if one is detected in configuration, otherwise it will use apr-iconv. If you don't want to ever use the native iconv implementation, you could probably force that in the configuration script. If the only issue is the packaging (modules vs monolithic), that likely could be addressed by some fancy macro usage and inclusion of the current code base. If someone wants me to attempt it, I'd me willing to give it a shot. It appears that none of the potential iconv implementations has a vibrant community and that trading the dormant apr-iconv community for a dormant FreeBSD iconv community might not buy us much if the major issue with apr-iconv is packaging.
Re: apr-iconv 1.0
At 12:28 PM 3/31/2005, Curt Arnold wrote: On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote: I'm sure we can think of something, but if you say that we can not use native WIN32, then we could at least offer the option to use gnu-iconv for win32 builds as well, or any other iconv-api library. How could gnu-iconv be an option for an Apache project due to the license conflicts? There don't seem to be any appropriate iconv implementations for Windows. Two separate issues. Apache projects regularly support linking to gnu libraries, such as the native install of regex or expat or whatever code the GNU communities have co-opted. I'm against providing GNU-only services from apr, and believe many here agree. I don't agree with inhibiting the same. The user should be able to configure for either, if that's what they want to do. The difference, we wouldn't distribute a binary linked to GNU code from the foundation. If third parties care to, that's fine. I don't have any objection to Mladen's suggestion, as one alternative among many. Like said, I think that we should either build our own implementation of iconv functionality, or just build a wrapper over existing one. Mladen, you didn't define 'we'. The apr project has proved less than enthusiastic about creeping featurism. 'We' definitely want out from iconv support, from the majority of posts I've read. So, I see the future of apr-iconv as ASF implementation of iconv, with iconv abstraction layer moved to apr-utils, that will use apr-iconv, as just one of the flavors of iconv api. I'm not sure how that is different that the current state. Currently, apr_xlate in apr-util will use a native iconv implementation if one is detected in configuration, otherwise it will use apr-iconv. If you don't want to ever use the native iconv implementation, you could probably force that in the configuration script. More to the point, we should have some iconv code base to rely on. A wider community iconv implementation. Not one which is hacked beyond recognition to use the apr interface, which enjoys only limited adoption. If the only issue is the packaging (modules vs monolithic), that likely could be addressed by some fancy macro usage and inclusion of the current code base. If someone wants me to attempt it, I'd me willing to give it a shot. It appears that none of the potential iconv implementations has a vibrant community and that trading the dormant apr-iconv community for a dormant FreeBSD iconv community might not buy us much if the major issue with apr-iconv is packaging. Those are implementation details. I've added Mladen to the list of individuals interested in seeing a BSD-licensed iconv project. Brane was already on that list, and I'm inquiring in the BSD and the newlib communities. Should I add you to that list as an interested participant, Curt? Bill
Re: apr-iconv 1.0
On Mar 31, 2005, at 1:23 PM, William A. Rowe, Jr. wrote: At 12:28 PM 3/31/2005, Curt Arnold wrote: On Mar 31, 2005, at 5:27 AM, Mladen Turk wrote: I'm sure we can think of something, but if you say that we can not use native WIN32, then we could at least offer the option to use gnu-iconv for win32 builds as well, or any other iconv-api library. How could gnu-iconv be an option for an Apache project due to the license conflicts? There don't seem to be any appropriate iconv implementations for Windows. Two separate issues. Apache projects regularly support linking to gnu libraries, such as the native install of regex or expat or whatever code the GNU communities have co-opted. I'm against providing GNU-only services from apr, and believe many here agree. I don't agree with inhibiting the same. The user should be able to configure for either, if that's what they want to do. The difference, we wouldn't distribute a binary linked to GNU code from the foundation. If third parties care to, that's fine. I don't have any objection to Mladen's suggestion, as one alternative among many. Mladen's suggestion appeared to be drop apr-iconv and require Windows users of apr_xlate to depend on gnu iconv. Using gnu iconv as an option is okay, but it doesn't eliminate the need to provide or identify an iconv implementation that is consistent with the Apache License. More to the point, we should have some iconv code base to rely on. A wider community iconv implementation. Not one which is hacked beyond recognition to use the apr interface, which enjoys only limited adoption. If the only issue is the packaging (modules vs monolithic), that likely could be addressed by some fancy macro usage and inclusion of the current code base. If someone wants me to attempt it, I'd me willing to give it a shot. It appears that none of the potential iconv implementations has a vibrant community and that trading the dormant apr-iconv community for a dormant FreeBSD iconv community might not buy us much if the major issue with apr-iconv is packaging. Those are implementation details. I've added Mladen to the list of individuals interested in seeing a BSD-licensed iconv project. Brane was already on that list, and I'm inquiring in the BSD and the newlib communities. Should I add you to that list as an interested participant, Curt? I was trying to explain a course of action that could address one of the complaints (and maybe the major one) without needing to launch a new project or incorporate a new code base so I don't see it as just implementation details. Maybe a new BSD licensed iconv project might make that approach moot at some point in the future and we could drop apr-iconv, but it exists now and has a degree of familiarity. I've done a little exploration using macro instead of C++ namespaces and the most significant issues is that iconv_ccs_desc and iconv_ces_desc atr used both as a structure name and as a instance name and I can't use a macro to rename one without affecting the other. However, it would be a fairly insignificant change to change to names of the local instance variable so the structure and the instance can be distinguished. So unlike the namespace approach, it can't be done with no changes to the module code, but it can be done with a small change that does not affect their ability to still be used in the module based approach. I'm overbooked as it is. I am able to make do with the current apr-iconv and am only concerned with approaches that might leave me stranded without an option on Windows platforms.
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 06:04 PM 3/29/2005, Branko ibej wrote: The best solution would be to upgrade apr-iconv based on the iconv2 library, which doesn't use shared libraries for the charset files any longer (it uses generated binary files in a different format). This being the freebsd/newlib iconv 2.03? We have to find something compatible with the BSD license. I think so. It's a new version of the library we're based on already, by The Same Author, and it looks like it's the same license. -- Brane
Re: apr-iconv 1.0
At 10:09 PM 3/29/2005, Curt Arnold wrote: I'm unclear on the proposed resolution. Does it include a mechanism to distinguish apriconv-1 encoding modules from apriconv-0 modules either by changing the module signature or name? I believe we should do that, too. But it seems that some want us to use an 'external' iconv implementation, at least, as of the next major release of apr-util. With the files residing in /apriconv-1/*.so I'm less concerned with the signature. Without some mechanism to distinguish encoding modules, it really doesn't matter what order the paths are evaluated? If there is a mechanism, it shouldn't hurt to evaluate APR_ICONV_PATH first? Of course it would, because we would still have to iterate multiple .so files to find the correct one. This is a huge performance hit. So let me inquire - have you authored a custom (charset).so file, or intend to do so? Again, the consensus on list was that apr-iconv was an implementation-internal detail of apr-util. With the next release, implementors/users are expected to install the directory apriconv-1 in parallel to apriconv-1.so [.dll]. APR_ICONV_PATH would be searched last, to pick up those exceptions/custom charset modules. We wouldn't hit iconv/ at all (unless the user asks us to through APR_ICONV_PATH. So I'm confused if this solution doesn't resolve the issues of all users. Please explain further. On your point of avoiding conflicts by changing the signature, yes I would be -happy- to entertain a patch, if you want to post one in the next day. I'll be putting together my changes tomorrow eve, and would be easily able to integrate your suggestion if you care to offer the patch. I don't see it as a substitute for searching for the right file, but I see it as added security against loading the wrong module. Bill
Re: apr-iconv 1.0
On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote: At 10:09 PM 3/29/2005, Curt Arnold wrote: I'm unclear on the proposed resolution. Does it include a mechanism to distinguish apriconv-1 encoding modules from apriconv-0 modules either by changing the module signature or name? I believe we should do that, too. But it seems that some want us to use an 'external' iconv implementation, at least, as of the next major release of apr-util. With the files residing in /apriconv-1/*.so I'm less concerned with the signature. Are you expecting the apriconv-1 directory to be on the PATH or LD_LIBRARY_PATH or relative to a directory on the PATH or LD_LIBRARY_PATH? If it is on the PATH or LD_LIBRARY_PATH, then this is the continued possibility of collision with modules from other iconv implementations, if it is relative to an directory on the path, then I would expect that you would need add a decent amount of complexity to accomplish that. I would think it may be simpler to have modules named apriconv-1-ENCODING.so or .dll and have dlopen or LoadLibrary find them with their existing library search mechanisms, but I could understand if that was undesirable for other reasons. Without some mechanism to distinguish encoding modules, it really doesn't matter what order the paths are evaluated? If there is a mechanism, it shouldn't hurt to evaluate APR_ICONV_PATH first? Of course it would, because we would still have to iterate multiple .so files to find the correct one. This is a huge performance hit. So let me inquire - have you authored a custom (charset).so file, or intend to do so? No, I have no intention to do that. At this point, the resolution to the issue does not effect log4cxx since it will continue to hack apriconv to embed the encodings into log4cxx.dll and liblog4cxx.so. You need to do what is right for httpd and/or Subversion. Again, the consensus on list was that apr-iconv was an implementation-internal detail of apr-util. With the next release, implementors/users are expected to install the directory apriconv-1 in parallel to apriconv-1.so [.dll]. APR_ICONV_PATH would be searched last, to pick up those exceptions/custom charset modules. We wouldn't hit iconv/ at all (unless the user asks us to through APR_ICONV_PATH. Since Subversion sets APR_ICONV_PATH, there is still the possibility of finding an apriconv-0 encoding module if the installation is damaged (or the developer decides not to distribute some obscure encoding) or a new encoding gets added to Subversion and/or apriconv-0. So I'm confused if this solution doesn't resolve the issues of all users. Please explain further. On your point of avoiding conflicts by changing the signature, yes I would be -happy- to entertain a patch, if you want to post one in the next day. I'll be putting together my changes tomorrow eve, and would be easily able to integrate your suggestion if you care to offer the patch. I don't see it as a substitute for searching for the right file, but I see it as added security against loading the wrong module. By changing the signature, I meant changing the value of ICMOD_UC_CCS and ICMOD_UC_CES (currently 0x100 and 0x101). I don't know if this method of module identification is used elsewhere and if so, what other values are currently in use. If the encoding modules can't be distinguished by name, I think it is essential that they have a different magic value. Otherwise, you are just reducing the chances of a catastrophic failure by checking APR_ICONV_PATH last, not eliminating it. Putting myself in the position of the developer of some hypothetical app (and I couldn't have an iconv2 based solution), I would prefer that apriconv-1 encoding modules be named something like apriconv-1-utf-8.dll or libapriconv-1-utf-8.so and located using the established library search algorithms in dlopen or LoadLibrary. In deployment, these would likely be placed in the same directory as aprutil-1.dll or libaprutil-1.so or the executable if linked against a static aprutil-1. APR_ICONV_PATH could be ignored. If the user really wanted a new encoding, they could either place it in an already searched directory or add the directory to PATH or LD_LIBRARY_PATH. However, it would be good if we could get some comment from a Subversion developer.
Re: apr-iconv 1.0
At 12:36 AM 3/30/2005, Curt Arnold wrote: On Mar 29, 2005, at 11:13 PM, William A. Rowe, Jr. wrote: At 10:09 PM 3/29/2005, Curt Arnold wrote: I'm unclear on the proposed resolution. Does it include a mechanism to distinguish apriconv-1 encoding modules from apriconv-0 modules either by changing the module signature or name? I believe we should do that, too. But it seems that some want us to use an 'external' iconv implementation, at least, as of the next major release of apr-util. With the files residing in /apriconv-1/*.so I'm less concerned with the signature. Are you expecting the apriconv-1 directory to be on the PATH or LD_LIBRARY_PATH yes. or relative to a directory on the PATH or LD_LIBRARY_PATH? Well the directory apriconv-1 will reside in a directory pointed to by PATH/LD_LIBRARY_PATH/SHLIB_PATH. And (at least on win32) within the cwd as we also discover binaries that way. The theory is simple. We -found- libapriconv-1.so/.dll. We'd already loaded it. How? Because it resided in exactly those paths, or the subdirectory of the startup dir on win32. The trivial rule is that libapriconv-1/ directory must sit beside libapriconv-1.so/.dll. If it is on the PATH or LD_LIBRARY_PATH, then this is the continued possibility of collision with modules from other iconv implementations, if it is relative to an directory on the path, then I would expect that you would need add a decent amount of complexity to accomplish that. Not really. We concatenate two strings, or three. I would think it may be simpler to have modules named apriconv-1-ENCODING.so or .dll and have dlopen or LoadLibrary find them with their existing library search mechanisms, but I could understand if that was undesirable for other reasons. Hmmm. String concats are string concats. Visually, I believed a directory libapriconv-1 was more clear. I don't think adding the extra filename information buys us anything, since -all- iconv implementations have always shared the concept of a separate dir for loadable modules. Without some mechanism to distinguish encoding modules, it really doesn't matter what order the paths are evaluated? If there is a mechanism, it shouldn't hurt to evaluate APR_ICONV_PATH first? Of course it would, because we would still have to iterate multiple .so files to find the correct one. This is a huge performance hit. So let me inquire - have you authored a custom (charset).so file, or intend to do so? No, I have no intention to do that. At this point, the resolution to the issue does not effect log4cxx since it will continue to hack apriconv to embed the encodings into log4cxx.dll and liblog4cxx.so. You need to do what is right for httpd and/or Subversion. Ack. And I hope - do something that log4cxx ultimately adopts. Again, the consensus on list was that apr-iconv was an implementation-internal detail of apr-util. With the next release, implementors/users are expected to install the directory apriconv-1 in parallel to apriconv-1.so [.dll]. APR_ICONV_PATH would be searched last, to pick up those exceptions/custom charset modules. We wouldn't hit iconv/ at all (unless the user asks us to through APR_ICONV_PATH. Since Subversion sets APR_ICONV_PATH, there is still the possibility of finding an apriconv-0 encoding module if the installation is damaged (or the developer decides not to distribute some obscure encoding) or a new encoding gets added to Subversion and/or apriconv-0. Right, except that we would seek APR_ICONV_PATH last. Minimize the chance of a collision. But certainly, not exclude every possibility. So I'm confused if this solution doesn't resolve the issues of all users. Please explain further. On your point of avoiding conflicts by changing the signature, yes I would be -happy- to entertain a patch, if you want to post one in the next day. I'll be putting together my changes tomorrow eve, and would be easily able to integrate your suggestion if you care to offer the patch. I don't see it as a substitute for searching for the right file, but I see it as added security against loading the wrong module. By changing the signature, I meant changing the value of ICMOD_UC_CCS and ICMOD_UC_CES (currently 0x100 and 0x101). Ack. I don't know if this method of module identification is used elsewhere and if so, what other values are currently in use. If the encoding modules can't be distinguished by name, I think it is essential that they have a different magic value. Otherwise, you are just reducing the chances of a catastrophic failure by checking APR_ICONV_PATH last, not eliminating it. Yes. Putting myself in the position of the developer of some hypothetical app (and I couldn't have an iconv2 based solution), I would prefer that apriconv-1 encoding modules be named something like apriconv-1-utf-8.dll or libapriconv-1-utf-8.so and located using the established library search algorithms in dlopen or LoadLibrary. In deployment, these
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 12:36 AM 3/30/2005, Curt Arnold wrote: However, it would be good if we could get some comment from a Subversion developer. Agreed, and Branko's watching this thread. Yup. It might also be a good thing to ping Steve King of TortoiseSVN fame; TSVN also ships a hacked version of apr-iconv, I believe the hack is to ignore APR_ICONV_PATH. The issue IIRC is collision between memory allocators in different runtime librararies on Windows; but anyway, Steve should be able to explain. -- Brane
Re: apr-iconv 1.0
Branko ibej wrote: William A. Rowe, Jr. wrote: At 12:36 AM 3/30/2005, Curt Arnold wrote: However, it would be good if we could get some comment from a Subversion developer. Agreed, and Branko's watching this thread. Yup. It might also be a good thing to ping Steve King of TortoiseSVN fame; TSVN also ships a hacked version of apr-iconv, I believe the hack is to ignore APR_ICONV_PATH. The issue IIRC is collision between memory allocators in different runtime librararies on Windows; but anyway, Steve should be able to explain. The reasons why TSVN ships a patched version of apr-iconv: - the *.so files are actually dll's which require a specific C-runtime. This isn't a big problem if APR_ICONV_PATH points to a iconv compiled with VC6. But if it points to an iconv compiled with VC7, then programs not using the new c-runtime ( version 7) won't run anymore. A 'solution' to that problem would be to install the runtime in e.g. the system dir on windows, but even MS tells to _not_ do that. - every program which installs its own iconv lib might change the APR_ICONV_PATH variable (believe me: most programs _don't_ check if it's already set) and overwrite this with maybe an older version of the lib! - looking up the env variable isn't very fast, i.e. it takes more time to load the *.so modules than other methods. The changes I made to apr-iconv for TSVN: - add a DllMain() to iconv_module which caches the path to the *.so modules (i.e. the path is determined only once when the iconv dll is loaded, not for every *.so module) - this is a _very_ big speed improvement for Subversion which makes intensive use of *.so modules. - the path is determined like this now: (in the following description, THISPATH refers to the path where the libapriconv.dll is located, fetched via GetModuleFileName() API) 1. path exists THISPATH\iconv 2. path exists ..\THISPATH\iconv 3. use APR_ICONV_PATH by doing this, it's assured that a program like TSVN always uses the iconv lib it has installed itself. Only if it doesn't install the iconv lib itself or it can't be found in 1) or 2), then the APR_ICONV_PATH env variable is used to find the *.so modules. You can find the patched iconv_module.c file here: https://svn.collab.net/repos/tortoisesvn/trunk/ext/apr-iconv_patch/lib/iconv_module.c Ever since TSVN ships with this patched iconv version, we haven't had any more problems with other Subversion clients interfering or missing c-runtime dll's or memory leaks due to incompatible c-runtimes (according to MS, the version 6 and 7 of the c-runtime are not compatible and use different memory allocators which leads to memory leaks and even heap corruptions if a program uses the wrong version). So I'm not sure what you guys have planned to change in apr-iconv, but I strongly recommend that if you change something, get rid of the APR_ICONV_PATH (on windows at least), or at least use it as the last option like TSVN does now. Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.tigris.org
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: This is the original thread we discussed apr-iconv going forward in 1.0. It seemed at the time our conclusion was that apr-iconv would be an internal implementation, not for consumption by the outside world. Well, not sure if I already posted this, but anyhow. I've developed libxlate library about a year ago, so perhaps it deserves a second look. It can be integrated within apr-iconv, because it follows the iconv api. Since this is my code, I'm willing to donate it to ASF if accepted for apr-iconv. Unlike Konstantin's implementation, mine follows the gnu iconv concept with all data tables in a single file (.dll), and has some features like case folding, transliteration, etc... The source can be found at: http://people.apache.org/~mturk/libxlate.zip Regards, Mladen.
Re: apr-iconv 1.0
SteveKing wrote: The reasons why TSVN ships a patched version of apr-iconv: Thanks for the exhaustive report, Stefan. [...] 2. path exists ..\THISPATH\iconv Surely you mean THISPATH\..\iconv? -- Brane
Re: apr-iconv 1.0
Steve, This is exactly my desired solution. If you would like to submit your patch to the list (submissions by reference aren't accepted without extra hassles) I would very much like to adopt it. (Especially as opposed to reinventing it.) My proposal of LD_LIBRARY_PATH corresponds to the fact that Unix doesn't have the GetModuleFileName concept to figure out where the absolute path of the libapriconv-1.so module lies. Since we have to make exceptions for Win32, and HP/UX, I see no reason not to use the native solution to Win32. Incidentally, do we need to search DYLD_LIBRARY_PATH or LD_LIBRARY_PATH on OSX? Bill At 09:49 AM 3/30/2005, SteveKing wrote: Branko Čibej wrote: William A. Rowe, Jr. wrote: At 12:36 AM 3/30/2005, Curt Arnold wrote: However, it would be good if we could get some comment from a Subversion developer. Agreed, and Branko's watching this thread. Yup. It might also be a good thing to ping Steve King of TortoiseSVN fame; TSVN also ships a hacked version of apr-iconv, I believe the hack is to ignore APR_ICONV_PATH. The issue IIRC is collision between memory allocators in different runtime librararies on Windows; but anyway, Steve should be able to explain. The reasons why TSVN ships a patched version of apr-iconv: - the *.so files are actually dll's which require a specific C-runtime. This isn't a big problem if APR_ICONV_PATH points to a iconv compiled with VC6. But if it points to an iconv compiled with VC7, then programs not using the new c-runtime ( version 7) won't run anymore. A 'solution' to that problem would be to install the runtime in e.g. the system dir on windows, but even MS tells to _not_ do that. - every program which installs its own iconv lib might change the APR_ICONV_PATH variable (believe me: most programs _don't_ check if it's already set) and overwrite this with maybe an older version of the lib! - looking up the env variable isn't very fast, i.e. it takes more time to load the *.so modules than other methods. The changes I made to apr-iconv for TSVN: - add a DllMain() to iconv_module which caches the path to the *.so modules (i.e. the path is determined only once when the iconv dll is loaded, not for every *.so module) - this is a _very_ big speed improvement for Subversion which makes intensive use of *.so modules. - the path is determined like this now: (in the following description, THISPATH refers to the path where the libapriconv.dll is located, fetched via GetModuleFileName() API) 1. path exists THISPATH\iconv 2. path exists ..\THISPATH\iconv 3. use APR_ICONV_PATH by doing this, it's assured that a program like TSVN always uses the iconv lib it has installed itself. Only if it doesn't install the iconv lib itself or it can't be found in 1) or 2), then the APR_ICONV_PATH env variable is used to find the *.so modules. You can find the patched iconv_module.c file here: https://svn.collab.net/repos/tortoisesvn/trunk/ext/apr-iconv_patch/lib/iconv_module.c Ever since TSVN ships with this patched iconv version, we haven't had any more problems with other Subversion clients interfering or missing c-runtime dll's or memory leaks due to incompatible c-runtimes (according to MS, the version 6 and 7 of the c-runtime are not compatible and use different memory allocators which leads to memory leaks and even heap corruptions if a program uses the wrong version). So I'm not sure what you guys have planned to change in apr-iconv, but I strongly recommend that if you change something, get rid of the APR_ICONV_PATH (on windows at least), or at least use it as the last option like TSVN does now. Stefan -- ___ oo // \\ De Chelonian Mobile (_,\/ \_/ \ TortoiseSVN \ \_/_\_/The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.tigris.org
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote:
This is exactly my desired solution. If you would like to
submit your patch to the list (submissions by reference aren't
accepted without extra hassles) I would very much like to adopt
it. (Especially as opposed to reinventing it.)
Ok, patch attached.
You can also find the complete file TSVN uses here:
https://svn.collab.net/repos/tortoisesvn/trunk/ext/apr-iconv_patch/lib/iconv_module.c
Stefan
--
___
oo // \\ De Chelonian Mobile
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
Index: lib/iconv_module.c
===
--- lib/iconv_module.c (revision 159498)
+++ lib/iconv_module.c (working copy)
@@ -52,10 +52,46 @@
#define APR_ICONV_PATH APR_ICONV API_STRINGIFY(API_MAJOR_VERSION) _PATH
+#ifdef WIN32
+char moduledir1[APR_PATH_MAX] = {0};
+char moduledir2[APR_PATH_MAX] = {0};
+
+BOOL WINAPI DllMain(HINSTANCE hInst, DWORD fdwReason, LPVOID lpvReserved)
+{
+ char * dirend;
+ if (fdwReason == DLL_PROCESS_ATTACH)
+ {
+ ZeroMemory(moduledir1, APR_PATH_MAX);
+ ZeroMemory(moduledir2, APR_PATH_MAX);
+ GetModuleFileName(hInst, moduledir1, APR_PATH_MAX);
+ strcpy(moduledir2, moduledir1);
+ dirend = strrchr(moduledir1, '\\');
+ if (dirend)
+ {
+ *dirend = 0;
+ strcat(moduledir1, \\iconv);
+ }
+ dirend = strrchr(moduledir2, '\\');
+ if (dirend)
+ {
+ *dirend = 0;
+ dirend = strrchr(moduledir2, '\\');
+ if (dirend)
+ {
+ *dirend = 0;
+ strcat(moduledir2, \\iconv);
+ }
+ }
+ }
+ return TRUE;
+}
+
+#endif
+
static apr_status_t
iconv_getpathname(char *buffer, const char *dir, const char *name, apr_pool_t
*ctx)
{
-apr_status_t rv;
+apr_status_t rv;
apr_finfo_t sb;
apr_snprintf(buffer, APR_PATH_MAX, %s/%s.so, dir, name);
@@ -96,7 +132,20 @@
while (0 != (*ptr++ = apr_tolower(*name++)))
;
-if (!apr_env_get(ptr, APR_ICONV_PATH, subpool)
+#ifdef WIN32
+ if (iconv_getpathname(buf, moduledir2, buffer, subpool) == 0)
+ {
+ apr_pool_destroy(subpool);
+ return APR_SUCCESS;
+ }
+ if (iconv_getpathname(buf, moduledir1, buffer, subpool) == 0)
+ {
+ apr_pool_destroy(subpool);
+ return APR_SUCCESS;
+ }
+#endif
+
+if (!apr_env_get(ptr, APR_ICONV_PATH, subpool)
!apr_filepath_list_split(pathelts, ptr, subpool))
{
int i;
Re: apr-iconv 1.0
At 10:17 AM 3/30/2005, Mladen Turk wrote: William A. Rowe, Jr. wrote: I've developed libxlate library about a year ago, so perhaps it deserves a second look. It can be integrated within apr-iconv, because it follows the iconv api. Since this is my code, I'm willing to donate it to ASF if accepted for apr-iconv. The biggest issue is community. apr-iconv clearly hasn't enjoyed enough community to retain the code we have. Contributions and help are scattershot. Our choice to integrate to apr was a poor one, because it doesn't enjoy any adoption outside of the apr user community. Simply, our solution was overkill, and formatting changes made it difficult to maintain in sync with the wider community. libxlate, while it sounds like a slick idea, suffers the same issue. One key point Roy raises is that we shouldn't as a project suffer a dependency on a single individual. You would need to first submit this library to the incubator, and develop a community. I dare say the apr community isn't interested in the nuts-and-bolts of iconv/xlate/charset management. We weren't even interested in continuing serf, it moved from the apr project. You might also consider the apache commons project as a container for libxlate. One concern, you mention you are offering this code under the ASL2, and mention that it follows the GNU single-dll, table-based solution. Did you look at the GNU implementation? I've started a dialog with the BSD-licensed iconv community principals to rebuild some traction for that library. The Linux community couldn't care less, as iconv has been moving into clib. But those not using the gcc compiler will continue to experience issues with iconv support. Once your libxlate is an established project, I see no reason not to set up the detection and configuration code to allow it from apr-util. Choices are good. I'll submit this to vote now, anticipating we want some resolution but don't want to break existing users: Should we deprecate our apr-iconv as of apr-util 2.0? +1: wrowe -1: The resulting issue, plug the hole before apr-util 2.0 is ready. Until that happens, if the vote is affirmative, I'll be happy to modify apr.hw to reflect that apr_xlate is not available on Win32. Bill
Re: apr-iconv 1.0
On Mar 30, 2005, at 12:41 PM, William A. Rowe, Jr. wrote: Should we deprecate our apr-iconv as of apr-util 2.0? +1: wrowe -1: The resulting issue, plug the hole before apr-util 2.0 is ready. Until that happens, if the vote is affirmative, I'll be happy to modify apr.hw to reflect that apr_xlate is not available on Win32. If apr-iconv is an implementation detail of apr_xlate, then I don't see the significance of deprecating it. Either it (or a replacement) is needed to support apr_xlate on platforms that don't provide an iconv or apr_xlate needs to be deprecated or removed. I assume that Subversion is actually using apr_xlate or they would not have bothered with setting APR_ICONV_PATH. Does httpd use apr_xlate? If so, I don't see how you could deprecate apr_xlate or make it only available on Unix platforms.
Re: apr-iconv 1.0
At 01:02 PM 3/30/2005, Curt Arnold wrote: If apr-iconv is an implementation detail of apr_xlate, then I don't see the significance of deprecating it. Either it (or a replacement) is needed to support apr_xlate on platforms that don't provide an iconv or apr_xlate needs to be deprecated or removed. We drop it. Point users 'elsewhere'. Not Maintained Here sign on the door. Tarball moves to archive.apache.org. Perhaps same for svn repository. Obviously we want apr_xlate to point at -something- but the what would no longer be apr_iconv. I assume that Subversion is actually using apr_xlate or they would not have bothered with setting APR_ICONV_PATH. Does httpd use apr_xlate? If so, I don't see how you could deprecate apr_xlate or make it only available on Unix platforms. Well, subversion does use apr_xlate. But this was actually reported by our log4cxx devs, who tripped over the subversion copy when they thought they were using their own build.
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 01:02 PM 3/30/2005, Curt Arnold wrote: If apr-iconv is an implementation detail of apr_xlate, then I don't see the significance of deprecating it. Either it (or a replacement) is needed to support apr_xlate on platforms that don't provide an iconv or apr_xlate needs to be deprecated or removed. We drop it. Point users 'elsewhere'. Not Maintained Here sign on the door. Tarball moves to archive.apache.org. Perhaps same for svn repository. Obviously we want apr_xlate to point at -something- but the what would no longer be apr_iconv. Well, do we have a replacement? If not I don't see how we can seriously consider dropping apr-iconv at this point. apr-iconv is doing it's thing. The first actual discussion in months, if not years, has been the APR_ICONV_PATH thing, which is easily circumvented with the patch from Steve. Let's apply that patch and see from there. My bet is that either the discussion drops again and we can go for another year or two, or someone goes to the trouble of doing the actual replacement implementation (be that doing platform native calls or otherwise). Sander
Re: apr-iconv 1.0
On Wed, Mar 30, 2005 at 03:50:46PM -0600, Curt Arnold wrote: I don't think interpretation 1 could be supported since Subversion and likely httpd depend on apr_xlate and want to run on Windows platforms. This keeps coming up, so - just for the record; ./server/util.c ./server/util_charset.c ./server/util_script.c ./server/util_ebcdic.c ./modules/aaa/mod_authnz_ldap.c ./modules/experimental/mod_charset_lite.c ./modules/cache/mod_disk_cache.c ./modules/filters/mod_include.c ./include/util_ebcdic.h ./include/util_charset.h ./support/ab.c ./support/htdbm.c ./support/htdigest.c ./support/htpasswd.c from httpd depend on apr_xlate. I've had to meddle with apr-iconv to get mod_disk_cache working (ish) on win32 in the past, so there are definitely some dependencies from httpd. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: apr-iconv 1.0
At 03:50 PM 3/30/2005, Curt Arnold wrote: Well, subversion does use apr_xlate. But this was actually reported by our log4cxx devs, who tripped over the subversion copy when they thought they were using their own build. I made the initial report when attempting to use apr_xlate in log4cxx. Yup What I saw trying to say was that Subversion would likely have not set APR_ICONV_PATH in Windows unless they were using apr_xlate. Which they do. 2. Drop apr_iconv and support apr_xlate on platforms without a native iconv implementation using something else. Yes. Pick up the FreeBSD iconv 2.x with some win32 or other atypical unix deployment patches. I could support option 2, but would need to know the identity and licensing terms of the something else first. Again, FreeBSD iconv 2.x is maintained by Alexander, who hasn't had the cycles himself to devote to it, or a community around it. So, proposing a new community around it, either through the incubator with the ASL license, or still under the BSD license somewhere else (e.g. a sourceforge type location.) There are several communities who rely on the Kostantin implementation. (FWIW - he's dropped his advertising clause in a note to Alexander, but the incubator would probably wish to have something more affirmative from him.) I don't suggest we drop it from support in apr-util 1.0, but the next major point bump of apr-util. Provided it gels. FWIW - who else in this community wants to participate if such an ASL/BSD licensed iconv project grew up around the most current code for iconv? Bill
Re: apr-iconv 1.0
Colm, grep doesn't help here. Most of the references you cited are EBCDIC platform-specific uses of apr_xlate. Bill At 04:18 PM 3/30/2005, Colm MacCarthaigh wrote: On Wed, Mar 30, 2005 at 03:50:46PM -0600, Curt Arnold wrote: I don't think interpretation 1 could be supported since Subversion and likely httpd depend on apr_xlate and want to run on Windows platforms. This keeps coming up, so - just for the record; ./server/util.c ./server/util_charset.c ./server/util_script.c ./server/util_ebcdic.c ./modules/aaa/mod_authnz_ldap.c ./modules/experimental/mod_charset_lite.c ./modules/cache/mod_disk_cache.c ./modules/filters/mod_include.c ./include/util_ebcdic.h ./include/util_charset.h ./support/ab.c ./support/htdbm.c ./support/htdigest.c ./support/htpasswd.c from httpd depend on apr_xlate. I've had to meddle with apr-iconv to get mod_disk_cache working (ish) on win32 in the past, so there are definitely some dependencies from httpd. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED]
Re: LDAP changes in apr-util 1.0.x
William A. Rowe, Jr. said: Wouldn't it be *much* more economical to do something similar to apr_procattr_t, where we set up all the choices beforehand, and can reuse the apr_ldapopt_t over and over on each ldap connection for options which do not change? All the LDAP toolkits have this concept already - you just call ldap_set_option with a NULL ldap handle and you set system wide properties (like defaults, and SSL params). I ment from the perspective of apr_ldap() - for both an individual setting and global config. The trouble is that the LDAP toolkits give you two choices: system wide options, and per connection options tracked with a connection handle. Creating our own system wide apr_ldapopt_t isn't going to do anything for us that ldap_set_option() can't do for us already. The LDAP best practice seems to be: - set system defaults using ldap_set_option(NULL, ...) - create a possible connection using ldap_init() - optionally modify the connection (adding SSL, or TLS, or client certs, or whatever) using ldap_set_option() - actually make the connection using ldap_bind() I think we should stick as close to this as possible. So far OpenLDAP can fit this model, Novell can fit the model (by hiding ldap_start_tls_s and friends inside ldap_set_option), and Microsoft can handle this (like openldap, all the params can be set using ldap_set_option). APR doesn't allow us to remove functions until v2.x, so I am very keen to avoid adding arbitrary functions to APR and then regret their addition later. The issue is the supporting of client certificates - which in some cases (openldap, microsoft) are set on a per connection basis (which makes the most sense), and in other cases are set on a system wide sense (novell in my understanding). Yes, it will vary a bit. The global flavor apr_ldap_default_set() would be supported mostly everywhere, and per-connection options passed to apr_ldap_init() would be supported only if available. apr_ldap_default_set() can be achieved already by using apr_ldap_set_option(NULL, ...), and if the end user has used LDAP toolkits before (likely) they will expect APR to work in a similar way. I think we should keep to the principle of lease astonishment if we possibly can. Not only do we have to somehow handle this in APR, but we also need to handle this in httpd. Perhaps we need an httpd directive with global only scope that sets system wide certificates (AKA CA certs, but in the Novell case it could also be a client side cert valid system wide), as well as a local scoped per connection directive for client certificates (ie a per connection client cert, supported by Microsoft and OpenLDAP but fails with a graceful error on Novell). Well, the very same directives in the global config would help choose the 'default', while if restricted to a single ldap entry they would apply only to that host. I would still recommend keeping separate httpd config directives for system certs and client (per connection) certs. I have learned more about the Novell toolkit: Unlike the other toolkits, where CA certs are set all in one go, Novell expects you to specify multiple CA certs separately, one at a time. The easiest way to achieve this is to specify LDAPTrustedCA more than once. Novell client certs are specified using a different API, we can hide this inside apr_ldap_set_option() and we are laughing. Regards, Graham --
Re: LDAP changes in apr-util 1.0.x
Brad Nicholes said: The problem is that other SDKs such as Novell, do not use ldap_set_option() to set the certificates or the SSL mode. Novell uses ldapssl_add_trusted_cert() and ldapssl_start_tls(). As it stands the apr_ldap_add_cert() function allows you to add as many certificates as you like doing the correct thing for all SDKs under the covers. apr_ldap_init() is doing the right thing as far as starting SSL, TLS or clear ldap connection regardless of the SDK. Using apr_ldap_set_option() to set certificates or SSL modes would be SDK specific. It has to be abstracted by APR. That was exactly the point - it would be abstracted by APR. I think the concern seems to be that the API is getting messy, which is exactly the thing we're trying to move away from. It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. How are client certificates specified within the Novell toolkit? Regards, Graham --
Re: LDAP changes in apr-util 1.0.x
It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. After thinking about it a little more, is teaching apr_ldap_init() to support STARTTLS the right thing to do in apr-util? My understanding is that the purpose of start_tls is to be able to on the fly, convert back and forth between an unsecure connection and a secure connection when required. By teaching apr_ldap_init() to support start_tls, once you have created a secure connection on 389, it's permanent. You don't have the option, at least through apr-util, to initially create an unsecure connection and then at some later point, convert the connection to a secure connection. Or converting back to unsecure from secure. Should starting and stopping TLS be a separate API in apr-util rather than part of apr_ldap_init()? Brad Graham Leggett [EMAIL PROTECTED] Thursday, January 06, 2005 1:11 AM Brad Nicholes said: The problem is that other SDKs such as Novell, do not use ldap_set_option() to set the certificates or the SSL mode. Novell uses ldapssl_add_trusted_cert() and ldapssl_start_tls(). As it stands the apr_ldap_add_cert() function allows you to add as many certificates as you like doing the correct thing for all SDKs under the covers. apr_ldap_init() is doing the right thing as far as starting SSL, TLS or clear ldap connection regardless of the SDK. Using apr_ldap_set_option() to set certificates or SSL modes would be SDK specific. It has to be abstracted by APR. That was exactly the point - it would be abstracted by APR. I think the concern seems to be that the API is getting messy, which is exactly the thing we're trying to move away from. It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. How are client certificates specified within the Novell toolkit? Regards, Graham --
Re: LDAP changes in apr-util 1.0.x
It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. How are client certificates specified within the Novell toolkit? With the API's ldapssl_set_client_cert() and ldapssl_set_client_private_key() Brad Graham Leggett [EMAIL PROTECTED] Thursday, January 06, 2005 1:11 AM Brad Nicholes said: The problem is that other SDKs such as Novell, do not use ldap_set_option() to set the certificates or the SSL mode. Novell uses ldapssl_add_trusted_cert() and ldapssl_start_tls(). As it stands the apr_ldap_add_cert() function allows you to add as many certificates as you like doing the correct thing for all SDKs under the covers. apr_ldap_init() is doing the right thing as far as starting SSL, TLS or clear ldap connection regardless of the SDK. Using apr_ldap_set_option() to set certificates or SSL modes would be SDK specific. It has to be abstracted by APR. That was exactly the point - it would be abstracted by APR. I think the concern seems to be that the API is getting messy, which is exactly the thing we're trying to move away from. It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. How are client certificates specified within the Novell toolkit? Regards, Graham --
Re: LDAP changes in apr-util 1.0.x
Brad Nicholes wrote:
How are client certificates specified within the Novell toolkit?
With the API's ldapssl_set_client_cert() and
ldapssl_set_client_private_key()
Can you do this after ldap_init()?
My thinking is to teach apr_ldap_set_option(ld, APR_LDAP_OPT_TLS_*CERT*,
cert|key) to do this:
apr_ldap_set_option(ld, option, value) {
if (toolkit == novell) {
if (option = set-client-cert) {
ldapssl_set_client_cert()
return
}
if (option == set-client-key) {
ldapssl_set_client_private_key()
return
}
if (option == set-tls-to-start-tls) {
ldapssl_start_tls()
return
}
}
if (toolkit == microsoft) {
do microsoft flavoured stuff
return
}
// else default to simple setting of options
ldap_set_option(option, value)
}
This causes the Novell toolkit and Microsoft toolkit to behave like the
OpenLDAP toolkit, which has the cleanest interface out of all of them.
First you do apr_ldap_init(...secure = 0...), then you do
apr_set_option() for clients certs and starttls/ssl, then you do
ldap_bind().
The secure flag in apr_ldap_init() can be for legacy toolkits that
cannot support upgrading the connection after the fact, but my research
so far hasn't uncovered any toolkit where this is a problem.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
At 01:44 PM 1/6/2005, Graham Leggett wrote: Brad Nicholes wrote: How are client certificates specified within the Novell toolkit? With the API's ldapssl_set_client_cert() and ldapssl_set_client_private_key() Can you do this after ldap_init()? My thinking is to teach apr_ldap_set_option(ld, APR_LDAP_OPT_TLS_*CERT*, cert|key) to do this: Wouldn't it be *much* more economical to do something similar to apr_procattr_t, where we set up all the choices beforehand, and can reuse the apr_ldapopt_t over and over on each ldap connection for options which do not change? Bill
Re: LDAP changes in apr-util 1.0.x
William A. Rowe, Jr. wrote: Wouldn't it be *much* more economical to do something similar to apr_procattr_t, where we set up all the choices beforehand, and can reuse the apr_ldapopt_t over and over on each ldap connection for options which do not change? All the LDAP toolkits have this concept already - you just call ldap_set_option with a NULL ldap handle and you set system wide properties (like defaults, and SSL params). The issue is the supporting of client certificates - which in some cases (openldap, microsoft) are set on a per connection basis (which makes the most sense), and in other cases are set on a system wide sense (novell in my understanding). Not only do we have to somehow handle this in APR, but we also need to handle this in httpd. Perhaps we need an httpd directive with global only scope that sets system wide certificates (AKA CA certs, but in the Novell case it could also be a client side cert valid system wide), as well as a local scoped per connection directive for client certificates (ie a per connection client cert, supported by Microsoft and OpenLDAP but fails with a graceful error on Novell). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
At 04:11 PM 1/6/2005, Graham Leggett wrote: William A. Rowe, Jr. wrote: Wouldn't it be *much* more economical to do something similar to apr_procattr_t, where we set up all the choices beforehand, and can reuse the apr_ldapopt_t over and over on each ldap connection for options which do not change? All the LDAP toolkits have this concept already - you just call ldap_set_option with a NULL ldap handle and you set system wide properties (like defaults, and SSL params). I ment from the perspective of apr_ldap() - for both an individual setting and global config. The issue is the supporting of client certificates - which in some cases (openldap, microsoft) are set on a per connection basis (which makes the most sense), and in other cases are set on a system wide sense (novell in my understanding). Yes, it will vary a bit. The global flavor apr_ldap_default_set() would be supported mostly everywhere, and per-connection options passed to apr_ldap_init() would be supported only if available. Not only do we have to somehow handle this in APR, but we also need to handle this in httpd. Perhaps we need an httpd directive with global only scope that sets system wide certificates (AKA CA certs, but in the Novell case it could also be a client side cert valid system wide), as well as a local scoped per connection directive for client certificates (ie a per connection client cert, supported by Microsoft and OpenLDAP but fails with a graceful error on Novell). Well, the very same directives in the global config would help choose the 'default', while if restricted to a single ldap entry they would apply only to that host.
Re: LDAP changes in apr-util 1.0.x
With the API's ldapssl_set_client_cert() and
ldapssl_set_client_private_key()
Can you do this after ldap_init()?
I don't know for sure but as you described it below, it sounds
reasonable. As long as ldapssl_init (, , 0) is called for an unsecure
connection, my guess would be that as long as you called
ldapssl_start_tls() after the calls to ldapssl_set_client_cert() and
ldapssl_set_client_private_key(), it should work fine. But I would have
to try it to be sure.
Brad
Graham Leggett [EMAIL PROTECTED] Thursday, January 06, 2005 12:44
PM
Brad Nicholes wrote:
How are client certificates specified within the Novell toolkit?
With the API's ldapssl_set_client_cert() and
ldapssl_set_client_private_key()
Can you do this after ldap_init()?
My thinking is to teach apr_ldap_set_option(ld,
APR_LDAP_OPT_TLS_*CERT*,
cert|key) to do this:
apr_ldap_set_option(ld, option, value) {
if (toolkit == novell) {
if (option = set-client-cert) {
ldapssl_set_client_cert()
return
}
if (option == set-client-key) {
ldapssl_set_client_private_key()
return
}
if (option == set-tls-to-start-tls) {
ldapssl_start_tls()
return
}
}
if (toolkit == microsoft) {
do microsoft flavoured stuff
return
}
// else default to simple setting of options
ldap_set_option(option, value)
}
This causes the Novell toolkit and Microsoft toolkit to behave like the
OpenLDAP toolkit, which has the cleanest interface out of all of them.
First you do apr_ldap_init(...secure = 0...), then you do
apr_set_option() for clients certs and starttls/ssl, then you do
ldap_bind().
The secure flag in apr_ldap_init() can be for legacy toolkits that
cannot support upgrading the connection after the fact, but my research
so far hasn't uncovered any toolkit where this is a problem.
Regards,
Graham
--
LDAP changes in apr-util 1.0.x
The apr_ldap_option.h interfaces can't be added in a 1.0.x release, 1.0.x releases must be forward and backwards source-compatible with 1.0.0 per the versioning guidelines. I don't know if this one is supposed to be private-but-global or public API: ldap/apr_ldap_init.c: In function `apr_ldap_ssl_init': ldap/apr_ldap_init.c:52: warning: implicit declaration of function `apr_ldap_ssl_add_cert' ldap/apr_ldap_init.c: At top level: ldap/apr_ldap_init.c:110: warning: no previous prototype for 'apr_ldap_ssl_add_cert' it should be protototyped (and/or static), or removed from 1.0.x as appropriate... Regards, joe
Re: LDAP changes in apr-util 1.0.x
Joe Orton said: The apr_ldap_option.h interfaces can't be added in a 1.0.x release, 1.0.x releases must be forward and backwards source-compatible with 1.0.0 per the versioning guidelines. Ok... I will remove the patches from the apr v1.0 tree. This means that httpd v2.1.x now depends on apr v1.1.x - are there any obstacles in the way of cutting an official v1.1.0 release of APR in the next week or two? Regards, Graham --
Re: LDAP changes in apr-util 1.0.x
Graham Leggett wrote: Joe Orton said: The apr_ldap_option.h interfaces can't be added in a 1.0.x release, 1.0.x releases must be forward and backwards source-compatible with 1.0.0 per the versioning guidelines. Ok... I will remove the patches from the apr v1.0 tree. This means that httpd v2.1.x now depends on apr v1.1.x - are there any obstacles in the way of cutting an official v1.1.0 release of APR in the next week or two? I don't see any reason we couldn't roll a release, although since some newish stuff (like the multicast code) has recently gone in we might want to consider not including that, so as to give the API more time to prove itself before we set it in stone. -garrett
Re: LDAP changes in apr-util 1.0.x
Joe Orton wrote:
I'm still catching up from holiday stuff, but I presume you do mean just
apr-util not apr? I think it would be preferable if any dependencies on
apr{,-util}-1.1 in httpd were conditional at compile-time (using
ap?_version.h), but there should be no barriers to release other than
round tuits, unless there are any regressions recently.
Cool.
If there is a hard dependency it should be enforced at configure-time
and that requires more AP?_FIND_AP? hacking I expect! (which would be
more work than just removing the dependency :)
Which in turn means the platform specific stuff that required the API
change moves back into httpd, and suddenly we're back to #ifdef heaven.
I don't see any hassles about requiring that httpd depend on a certain
minimum APR (it does already - httpd v2.1 depends minimally on APR v1.0)
- the only issue is that there has been no official release of apr v1.1
yet for httpd to depend on.
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
Garrett Rooney wrote: I don't see any reason we couldn't roll a release, although since some newish stuff (like the multicast code) has recently gone in we might want to consider not including that, so as to give the API more time to prove itself before we set it in stone. If we delay, then we have the six release candidates of apr v1.0 all over again :( As long as the API is sound the multicast stuff should be fine in theory, bugfixes can go into a point release. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
Graham Leggett wrote: Garrett Rooney wrote: I don't see any reason we couldn't roll a release, although since some newish stuff (like the multicast code) has recently gone in we might want to consider not including that, so as to give the API more time to prove itself before we set it in stone. If we delay, then we have the six release candidates of apr v1.0 all over again :( As long as the API is sound the multicast stuff should be fine in theory, bugfixes can go into a point release. I'm not talking about delaying, I'm talking about making the release but excluding the multicast APIs from it. Multicast can make it into 1.2.x, once the API has stabalized and been implemented on some more platforms. -garrett
Re: LDAP changes in apr-util 1.0.x
Garrett Rooney wrote: I'm not talking about delaying, I'm talking about making the release but excluding the multicast APIs from it. Multicast can make it into 1.2.x, once the API has stabalized and been implemented on some more platforms. True, but removing the APIs means the code gets no exposure. It all depends on how confident the people who came up with the APIs are at their structure at the moment. Is the multicast API likely to change significantly? If so, then it does make sense to exclude it. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
Graham Leggett wrote: I don't see any hassles about requiring that httpd depend on a certain minimum APR (it does already - httpd v2.1 depends minimally on APR v1.0) - the only issue is that there has been no official release of apr v1.1 yet for httpd to depend on. Agreed. Let's do apr 1.1 -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: LDAP changes in apr-util 1.0.x
At 11:05 AM 1/5/2005, Jim Jagielski wrote: Graham Leggett wrote: I don't see any hassles about requiring that httpd depend on a certain minimum APR (it does already - httpd v2.1 depends minimally on APR v1.0) - the only issue is that there has been no official release of apr v1.1 yet for httpd to depend on. Agreed. Let's do apr 1.1 Let's collectively vet apr 1.1 new API changes (now, not a week from now) so we don't have to backtrack and deprecate things later. Remember we are committing to support interfaces upon each release on a minor bump. I'm working on httpd-2.1/apr-1.1 as I comment. Yes, apr-1.1 is about ready, and I agree that multicast can be deferred for apr-1.2. Bill
Re: LDAP changes in apr-util 1.0.x
Ewww... IIUC - apr_ldap_initialize(ldaps://foo/) was supposed to handle the ssl 'crap' for us. If we are just exposing OpenLDAP and Novell LDAP, -1 for this change, and I'd like to propose we deprecate the whole shooting match for ldap. Consider apr_dbm. We don't expect or require users to consider the nuances of each dbm provider, we provide one constant macro. What apr-util should not become is some binding to require a ton of libs that the module can do for themselves. FWIW - I can see functions such as apr_ldap_ssl_key(char*cert, char*ca) which would require the user to know that cert/ca are symbolic names on Windows, Sun, etc, and actual file names for OpenLDAP. Some APR_ macro would be required to point this out to the application. Bill At 07:24 AM 1/5/2005, you wrote: The apr_ldap_option.h interfaces can't be added in a 1.0.x release, 1.0.x releases must be forward and backwards source-compatible with 1.0.0 per the versioning guidelines. I don't know if this one is supposed to be private-but-global or public API: ldap/apr_ldap_init.c: In function `apr_ldap_ssl_init': ldap/apr_ldap_init.c:52: warning: implicit declaration of function `apr_ldap_ssl_add_cert' ldap/apr_ldap_init.c: At top level: ldap/apr_ldap_init.c:110: warning: no previous prototype for 'apr_ldap_ssl_add_cert' it should be protototyped (and/or static), or removed from 1.0.x as appropriate... Regards, joe
Re: LDAP changes in apr-util 1.0.x
William A. Rowe, Jr. wrote: Ewww... IIUC - apr_ldap_initialize(ldaps://foo/) was supposed to handle the ssl 'crap' for us. If we are just exposing OpenLDAP and Novell LDAP, -1 for this change, and I'd like to propose we deprecate the whole shooting match for ldap. apr_ldap_initialise() presently makes the erroneous assumption that you only ever want to specify one certificate per connection. Perhaps a better way of doing this is to allow the apr_ldap_initialise() function to be called more than once - if you want two certs, just call apr_ldap_initialise() twice. This removes the need to have a separate apr_ldap_ssl_add_cert() function entirely. Another fun issue is support for client certificates. No provision has been made to pass client certificates to apr_ldap_init(). I spent some time Googling for best practises for doing SSL/TLS in LDAP, and the consensus seems to be that all the weird ldap*ssl*init() and ldap*start*tls*s() functions are deprecated in favour of setting all TLS related parameters via ldap_set_option(). This is the thinking behind adding the apr_ldap_option API. Current LDAP best practise seems to be: - call ldap_init() once. - call ldap_set_option() zero or more times, specifying SSL mode (SSL, STARTTLS, none), client certs, CA certs, whatever. - call apr_ldap_bind() to actually bind to the server. The question now is, can we emulate the above simple approach in APR by hiding ldap_start_tls_s() and ldap_ssl_add_cert() and all the other nonsense inside ldap_set_option()? The APR LDAP stuff is designed to fail cleanly - if something cannot be done, APR returns a human readable message explaining as best as it can what could not be done, to save the calling application from having to jump through hoops translating error codes into something a human can understand. This means that we do not have to implement every single feature in every single toolkit, if something is not practical we can gracefully bow out and say sorry, but what you just tried to do isn't supported in this toolkit (yet). Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: LDAP changes in apr-util 1.0.x
The problem is that other SDKs such as Novell, do not use ldap_set_option() to set the certificates or the SSL mode. Novell uses ldapssl_add_trusted_cert() and ldapssl_start_tls(). As it stands the apr_ldap_add_cert() function allows you to add as many certificates as you like doing the correct thing for all SDKs under the covers. apr_ldap_init() is doing the right thing as far as starting SSL, TLS or clear ldap connection regardless of the SDK. Using apr_ldap_set_option() to set certificates or SSL modes would be SDK specific. It has to be abstracted by APR. Brad Graham Leggett [EMAIL PROTECTED] Wednesday, January 05, 2005 3:33:37 PM William A. Rowe, Jr. wrote: Ewww... IIUC - apr_ldap_initialize(ldaps://foo/) was supposed to handle the ssl 'crap' for us. If we are just exposing OpenLDAP and Novell LDAP, -1 for this change, and I'd like to propose we deprecate the whole shooting match for ldap. apr_ldap_initialise() presently makes the erroneous assumption that you only ever want to specify one certificate per connection. Perhaps a better way of doing this is to allow the apr_ldap_initialise() function to be called more than once - if you want two certs, just call apr_ldap_initialise() twice. This removes the need to have a separate apr_ldap_ssl_add_cert() function entirely. Another fun issue is support for client certificates. No provision has been made to pass client certificates to apr_ldap_init(). I spent some time Googling for best practises for doing SSL/TLS in LDAP, and the consensus seems to be that all the weird ldap*ssl*init() and ldap*start*tls*s() functions are deprecated in favour of setting all TLS related parameters via ldap_set_option(). This is the thinking behind adding the apr_ldap_option API. Current LDAP best practise seems to be: - call ldap_init() once. - call ldap_set_option() zero or more times, specifying SSL mode (SSL, STARTTLS, none), client certs, CA certs, whatever. - call apr_ldap_bind() to actually bind to the server. The question now is, can we emulate the above simple approach in APR by hiding ldap_start_tls_s() and ldap_ssl_add_cert() and all the other nonsense inside ldap_set_option()? The APR LDAP stuff is designed to fail cleanly - if something cannot be done, APR returns a human readable message explaining as best as it can what could not be done, to save the calling application from having to jump through hoops translating error codes into something a human can understand. This means that we do not have to implement every single feature in every single toolkit, if something is not practical we can gracefully bow out and say sorry, but what you just tried to do isn't supported in this toolkit (yet). Regards, Graham --
Re: svn commit: r122648 - /apr/apr-util/branches/1.0.x/CHANGES /apr/apr-util/branches/1.0.x/build/apu-conf.m4
On Fri, Dec 17, 2004 at 04:11:19PM -, Graham Leggett wrote:
--- apr/apr-util/branches/1.0.x/build/apu-conf.m4 (original)
+++ apr/apr-util/branches/1.0.x/build/apu-conf.m4 Fri Dec 17 08:11:18 2004
@@ -275,8 +275,12 @@
test ${apu_has_ldap} != 1 AC_MSG_ERROR(could not find an LDAP
library)
AC_CHECK_LIB(lber, ber_init)
-AC_CHECK_HEADERS(ldap.h, ldap_h=[#include ldap.h])
AC_CHECK_HEADERS(lber.h, lber_h=[#include lber.h])
+AC_CHECK_HEADERS(ldap.h, ldap_h=[#include ldap.h], [],
+[#if HAVE_LBER_H
+# include lber.h
+# endif
+])
This breaks with autoconf 2.13. Is everyone happy with requiring
autoconf 2.5x for the 1.0.x branch too?
joe
Re: svn commit: r122648 - /apr/apr-util/branches/1.0.x/CHANGES /apr/apr-util/branches/1.0.x/build/apu-conf.m4
Joe Orton wrote: +AC_CHECK_HEADERS(ldap.h, ldap_h=[#include ldap.h], [], +[#if HAVE_LBER_H +# include lber.h +# endif +]) This breaks with autoconf 2.13. Is everyone happy with requiring autoconf 2.5x for the 1.0.x branch too? Is there another way of doing this without breaking autoconf 2.13? Solaris' LDAP library expects lber.h to be loaded before ldap.h. ldap.h does not work on it's own. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: svn commit: r122648 - /apr/apr-util/branches/1.0.x/CHANGES /apr/apr-util/branches/1.0.x/build/apu-conf.m4
On Fri, Dec 17, 2004 at 09:08:12PM +0200, Graham Leggett wrote: Joe Orton wrote: +AC_CHECK_HEADERS(ldap.h, ldap_h=[#include ldap.h], [], +[#if HAVE_LBER_H +# include lber.h +# endif +]) This breaks with autoconf 2.13. Is everyone happy with requiring autoconf 2.5x for the 1.0.x branch too? Is there another way of doing this without breaking autoconf 2.13? Preferably following the good example from apr/configure.in: AC_CACHE_CHECK([for netinet/tcp.h], [apr_cv_hdr_netinet_tcp_h], ... but optionally following the bad example: ac_includes_default=$ac_includes_default #if HAVE_SYS_MUTEX_H /* needed to define lock_t for sys/shm.h */ ... Solaris' LDAP library expects lber.h to be loaded before ldap.h. ldap.h does not work on it's own.
[announce] APR 1.0 Tutorial at ApacheCon
Sorry for the spam, but I just wanted to get the word out about the APR 1.0 Tutorial that Sander and I are doing at ApacheCon. We're hoping that some of you all who lurk on these lists and are interested in learning more about APR and the interface and features it provides might be able to convince your bosses to pay for you to come to the con and attend our tutorial. It's a three hour in-depth look at APR and how to use it. The full abstract is below. If you're interested, sign up asap -- if the number of people registered doesn't improve soon we might have to cancel the class altogether. Hope to see you there, Cliff T03: Apache Portable Runtime 1.0 Tutorial Day: Sat Time: 09h00 Session chair: None assigned Duration: 180 minutes Style: Tutorial Level: Experienced Audience: Developer Categories: Speaker: Cliff Woolley Speaker: Sander Striker As any systems programmer will know, one of the biggest headaches in writing a cross-platform application is dealing with the inconsistencies between various operating systems when trying to accomplish a given task. The Apache Portable Runtime is a portability library that seeks to bridge the gaps among these different platforms by providing a consistent interface for them all while attempting to provide maximum performance on each. It forms the underpinnings of both the Apache HTTP Server 2.0 and the Subversion revision control system, among other applications, freeing them from having to handle each new operating system as a special case. Though APR has been in development for several years, version 1.0 has finally hit the streets in its final form. This tutorial will give an overview of the features and APIs provided by APR 1.0 plus examples of how to use these features to make your own applications portable with ease. We will also demonstrate how APR's subsystems can be used together to build more complex applications by using them to construct a simple, portable web client that can fetch pages from a webserver and write them to disk.
1.0: socket_bucket_read() fails to handle blocking flags
socket_bucket_read() still fails to handle the blocking flag. Are you OK releasing APR 1.0 with this bug? For details please see: http://marc.theaimsgroup.com/?t=10840182852r=1w=2 The latest solution proposal was from Joe: On Mon, 17 May 2004, Joe Orton wrote: I'd hoped some friendly buckets guru would step in here :) I guess if it's correct to solve this at bucket-level, the solution is to make socket_bucket_read() check whether the socket is non-blocking on each call, and temporarily set the timeout to -1 if it is... but it has died there :( -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 1.0: socket_bucket_read() fails to handle blocking flags
On Thu, Aug 12, 2004 at 12:12:38AM -0700, Stas Bekman wrote: socket_bucket_read() still fails to handle the blocking flag. Are you OK releasing APR 1.0 with this bug? For details please see: http://marc.theaimsgroup.com/?t=10840182852r=1w=2 I took a further look at this a while back, and it looked like the fix I suggested was not portable: setting a timeout on a non-blocking socket has no effect on Win32. http://marc.theaimsgroup.com/?l=apr-devm=106561692726135w=2 so I'm out of ideas. The latest solution proposal was from Joe: On Mon, 17 May 2004, Joe Orton wrote: I'd hoped some friendly buckets guru would step in here :) I guess if it's correct to solve this at bucket-level, the solution is to make socket_bucket_read() check whether the socket is non-blocking on each call, and temporarily set the timeout to -1 if it is... but it has died there :( -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 1.0: socket_bucket_read() fails to handle blocking flags
Joe Orton wrote: On Thu, Aug 12, 2004 at 12:12:38AM -0700, Stas Bekman wrote: socket_bucket_read() still fails to handle the blocking flag. Are you OK releasing APR 1.0 with this bug? For details please see: http://marc.theaimsgroup.com/?t=10840182852r=1w=2 I took a further look at this a while back, and it looked like the fix I suggested was not portable: setting a timeout on a non-blocking socket has no effect on Win32. http://marc.theaimsgroup.com/?l=apr-devm=106561692726135w=2 so I'm out of ideas. :( The latest solution proposal was from Joe: On Mon, 17 May 2004, Joe Orton wrote: I'd hoped some friendly buckets guru would step in here :) I guess if it's correct to solve this at bucket-level, the solution is to make socket_bucket_read() check whether the socket is non-blocking on each call, and temporarily set the timeout to -1 if it is... but it has died there :( -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
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: 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: 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]
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
At 12:26 PM 7/30/2004, Graham Leggett wrote: William A. Rowe, Jr. wrote: 4. our APR_HAS_XXX_LDAPSDK macros are entirely bogus, still, on unix. Explain? (so I can fix). Here's my philosophy. First, we don't set up the HAS_BAR_LDAPSDK 0 values after setting the HAS_FOO_LDAPSDK 1 value. So this is a bug. But everything that we do relative to 'which toolkit is this?' should be behind the apu_private.h section, can use the classic HAVE_FOO_LDAP style macros, and shouldn't be shared. If we are describing ldap in terms of 'which toolkit?' then we didn't go to enough effort in apr-util/ldap to make this even worthwhile. My 2c. 5. we *bogusly* define ldap_memfree and ldap_search_ext_s in the *ldap*'s namespace. This is absolutely incorrect, and will immediately cause any ldap-based code to fail once the ldap library is upgraded (symbolic duplicates.) I plan to change all the apr defined ldap functions to be apr_ldap - will this fix this? Ack :) But I would ask, please, wrap behind functions not macros. In that way, changing the aprutil-1.so file can immediately result in using an alternate ldap provider. Thanks for getting excited about this - 'finishing' ldap apr support is good. I simply asked because releasing the 'old ldap' support as 1.0 would have dug us a deep hole, it would have been easier to release, sans ldap, then reintroduce in 1.1. But since you have the energy and motivation to just get it right - kudos and my thanks. Bill
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
I wish I was going to be at LinuxWorld but I guess that means that I have a little more time to review. Looking forward to seeing the code. Also if anybody else has time to review the current util_ldap backport proposals, I would like to get that done and into 2.0, otherwise the modules remain broken in 2.0 (AFAIK the stuff works great in 2.1). We might get a little more help on the rest of the LDAP code if what already exists really worked. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Friday, July 30, 2004 11:43:58 AM William A. Rowe, Jr. wrote: ++1 - so that makes three. Who minds writing it though? On the case now. Will check in the stuff for review, then if people are happy I will make the changes to httpd to use the new stuff in apr-util. Regards, Graham --
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
Brad Nicholes wrote: I wish I was going to be at LinuxWorld but I guess that means that I have a little more time to review. Looking forward to seeing the code. Also if anybody else has time to review the current util_ldap backport proposals, I would like to get that done and into 2.0, otherwise the modules remain broken in 2.0 (AFAIK the stuff works great in 2.1). We might get a little more help on the rest of the LDAP code if what already exists really worked. A question: The LDAP SDK returns error codes. How should provision be made for them? Should we be mapping them to APR_ namespace protected codes? If so, how? It seems errorno handling is done in apr, not apr-util - but apr doesn't have any knowledge of LDAP. Where should this be handled? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util/ldap/ - sink or really swim to 1.0 release?
The LDAP error codes probably shouldn't be mapped to the APR error namespace. Maybe the const char **reason should be changed to apr_ldap_err_t *reason instead. This structure could hold the native LDAP error code as well as any other information. The actual return code from the function could then be APR_SUCCESS, any other APR_ error if appropriate or APR_EGENERAL meaning check the apr_ldap_err_t structure for more information. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com Graham Leggett [EMAIL PROTECTED] Friday, July 30, 2004 12:11:57 PM Brad Nicholes wrote: I wish I was going to be at LinuxWorld but I guess that means that I have a little more time to review. Looking forward to seeing the code. Also if anybody else has time to review the current util_ldap backport proposals, I would like to get that done and into 2.0, otherwise the modules remain broken in 2.0 (AFAIK the stuff works great in 2.1). We might get a little more help on the rest of the LDAP code if what already exists really worked. A question: The LDAP SDK returns error codes. How should provision be made for them? Should we be mapping them to APR_ namespace protected codes? If so, how? It seems errorno handling is done in apr, not apr-util - but apr doesn't have any knowledge of LDAP. Where should this be handled? Regards, Graham --
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: [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: [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: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 12:46 PM 7/2/2004, Branko ibej wrote: William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko ibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. ++1 to that idea, as long as apr-util internally gets the -I / -L paths to the build of apr-iconv, and they don't persist in the apu-1-config file. Unless I'm totally blind, the Unix and Netware apr-util builds don't even have configury to use apr-iconv. Which means the above condition is already met, and we simply have to stop installing the apr-iconv headers on Windows. -- Brane
Re: apr-iconv 1.0
While we're on the subject of apr-iconv...
I'd like to reconsider the use of the APR_ICONV_PATH environment
variable. It turns out it's evil if you have to install two different
versions of apr_iconv in parallel. Also, on Windows, there's an issue of
different runtime libraries used by different compilers, and in
Subversion (or rather TortoiseSVN), we've seen instances where these can
interfere because of the use of this env. var.
Therefore I propose to change the way apr_iconv looks for the loadable
conversion modules in 1.0.
* Remove APR_ICONV_PATH
* On Unix, hardcode the path to the modules, using standard
configury. The default would be ${prefix}/lib/apr-iconv-${major},
or some such.
* On Windows, we'd calculate the path relative to the location of
the libapriconv-1.dll library; e.g.,
GerModuleFileName(0)/apr-iconv. Alternatively, the application
could pass in the root path, but we'd have to add an
initialization API -- we'd need something like that for the
statically-linked version.
Thoughts? I think 1.0 is an auspicious time to make this change,
especially if we declare apr-iconv to be an implementation detail of
apr_xlate.
William A. Rowe, Jr. wrote:
I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they
are seperate subsets with their own set of issues.
APR 1.0 does not require apr-util or apr-iconv, there is no dependency.
So no holdup of David's plans.
I'm proposing we switch around apr-iconv's interface to:
1) change typedef void *apr_icon_t; to an incomplete type, e.g.
typedef struct apr_icon_t apr_icon_t;
2) consistently use an apr_icon_t * or (for create) apr_icon_t **
as the arguments to the exposed functions.
3) reorder apr_iconv_open to pass the new apr_iconv_t ** placeholder
as the first not last arg, consistent with apr.
4) drop apr_pool_t argument from _close, that should use the same pool
as the associated _open.
I'm not suggesting using the apr_iconv_open()ed pool for xlate operations,
those may be in a frequently recycled pool, as oppsed to a long lived
pool used for apr_iconv_open (_close).
Of course, the apr_pool_t *p becomes a member of our internal apr_iconv_t
structure.
Thoughts?
Bill
-- Brane
RE: remaining issues prior to 1.0?
While researching -ctime thoughts on list... (the entire thread might be enlightening to review for those who want some weekend reading :) Nearly a year ago, At 11:09 AM 6/25/2003, William A. Rowe, Jr. wrote: At 03:27 AM 6/25/2003, Marc M. Adkins wrote: * emulating the daemon/services foo within the Win32 port... but call it a 'nice to have' ... I will try to dedicate cycles to this over the summer. It's not exactly a showstopper. Can you expand on this? Are you talking about the usual Windows doesn't fork problem, emulating Windows services on Linux, getting process data (memory size, CPU %, etc.) or something else entirely? Just curious. although I would *really* like to deal with fork() ... it isn't practical (topic for another thread). I was restricting my focus to mapping Service 'Events' - Unix Signals, such as stop, start, shutdown, and marking Apache as 'already daemonized' when you start as a service. My only headache - I spent some time trying to find how we can safely assert that this WinNT/2K/XP/2003 process is running within the SCM (NT kernel service control manager). The short answer so far; it isn't very pretty. If we knew that, we would have APR react and start a service control thread, and then enter the NT event processing loop. On the Win9x side, implement daemonize_process to dismiss the window and mark the process as a 'psuedo-service'. Again, the hidden window we create to track Apache shutting down would trigger our 'unix' signals. so it looks on NT as apr_app_initialize() \- Running as service? \- Spin up service monitor and nt eventlog capture thread for stderr \- In service monitor thread, call into the SCM to be called back. \- Fix the argv[] based on the ServiceStart args. and then react to service control signals to the monitor thread based on our apr_signals() API. The only other two big thorns left in APR? File Create time isn't the same as the inode modified ctime. And we don't have an API to map ACL management between implementations, nor a way for Win32 to handle setuid(). In Win32's case, we need the account 'password' to deal with a setuid() request. The first is a real bug to fix, the second is perhaps beyond the scope of releasing 1.0. And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would
Re: apr-iconv 1.0
At 06:41 PM 7/1/2004, Branko Čibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) What is troubling us most, at this instant, are those things that change the API in such a way that developer's code would be broken fixing the problems of APR 1.0.0. As long as they are internal details (default pathing, etc) then we won't be troubled by getting it right a little later. Bill
RE: remaining issues prior to 1.0?
At 02:24 AM 7/2/2004, William A. Rowe, Jr. wrote: [...] And in hind site - I don't see any reason we can't implement signals on win32 using the existing API. The ctime issue was brought up again and seems to be pretty important. And mapping ACL's on HPUX/Win32 and Linux/SE seems like it's own ballgame that would ... be it's own incremental version bump, e.g. 1.1 or whatnot. No need to hold up 1.0. Sorry, full of incomplete thoughts today - it's been a long week. Bill
Re: apr-util 1.0 rc2
David Reid wrote: Tagged! The rpm spec files for apr and apr-util are now working, can the relevant files be included inside RC3? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: apr-util 1.0 rc2
David Reid wrote: Tagged! The rpm spec files for apr and apr-util are now working, can the relevant files be included inside RC3? Having just gotten home (to a torrent of emails as per usual) and seen that apparently there is more dissent about even tagging RC3 today... In simple terms, I see no problem with including them at all. When RC3 is rolled I'll include them. david
Re: apr-iconv 1.0
William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko ibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. What is troubling us most, at this instant, are those things that change the API in such a way that developer's code would be broken fixing the problems of APR 1.0.0. As long as they are internal details (default pathing, etc) then we won't be troubled by getting it right a little later. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. -- Brane
Re: apr-iconv 1.0
At 12:46 PM 7/2/2004, Branko Äibej wrote: William A. Rowe, Jr. wrote: At 06:41 PM 7/1/2004, Branko Ãibej wrote: Thoughts? I think 1.0 is an auspicious time to make this change, especially if we declare apr-iconv to be an implementation detail of apr_xlate. The nifty bit is, if we declare apr-iconv to be an internal, implementation detail of apr_xlate - we are free to adopt your suggestions in 1.0.1 :) That's true. Then I suggest we really do close off apr-iconv. This means the apr-iconv headers shouldn't get installed, right? Among other things. ++1 to that idea, as long as apr-util internally gets the -I / -L paths to the build of apr-iconv, and they don't persist in the apu-1-config file. Bill
[PATCH APR 1.0] crtime v.s. intime
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.
BillIndex: 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 2 Jul 2004 20:01:09 -
@@ -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 2 Jul 2004 20:01:10 -
@@ -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 2 Jul 2004 20:01:10 -
@@ -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,
+apr_os2_time_to_apr_time(finfo-crtime, fstatus-fdateCreation,
fstatus-ftimeCreation );
finfo-valid = APR_FINFO_TYPE | APR_FINFO_PROT | APR_FINFO_SIZE
| APR_FINFO_CSIZE | APR_FINFO_MTIME
- | APR_FINFO_CTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
+ | APR_FINFO_CRTIME | APR_FINFO_ATIME | APR_FINFO_LINK;
}
Index: file_io/unix/filestat.c
===
RCS file: /home/cvs/apr/file_io/unix/filestat.c,v
retrieving revision 1.72
diff -u -r1.72 filestat.c
--- file_io/unix/filestat.c 27 Mar 2004 13:11:17 - 1.72
+++ file_io/unix/filestat.c 2 Jul 2004 20:01:10 -
@@ -69,7 +69,8 @@
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
+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);
@@ -81,7 +82,7 @@
finfo-nlink = info-st_nlink;
apr_time_ansi_put(finfo-atime, info-st_atime);
apr_time_ansi_put(finfo-mtime, info-st_mtime);
-apr_time_ansi_put(finfo-ctime, info-st_ctime);
+apr_time_ansi_put(finfo-intime, info-st_ctime);
/* ### needs to be revisited
* if (wanted APR_FINFO_CSIZE) {
* finfo-csize = info-st_blocks * 512;
Index: file_io/win32/filestat.c
===
RCS file: /home/cvs/apr/file_io/win32/filestat.c,v
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: 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: 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
TR for 1.0
Well, the last issue seems to have been resolved and by the flurry of patches I guess folks are looking at the code?! So, I'll aim to create 1.0 RC2 tarballs later on tonight/tomorrow and then if all is well we'll release a 1.0 :-) david
Re: apr-iconv 1.0
At 06:30 PM 6/23/2004, David Reid wrote: I'd like to suggest we hold our horses on apr-util and apr-iconv 1.0 - they are seperate subsets with their own set of issues. APR 1.0 does not require apr-util or apr-iconv, there is no dependency. So no holdup of David's plans. Well, I'd agree on apr-iconv (haven't even rolled a 1.0 rc yet) but apr-util needs to be released the same time as apr. Our 2 biggest users (httpd svn) both use both (if that makes sense) so if we have apr 1.0, we have apr-util 1.0. Well, we can't ignore apr-iconv, apr-util has a dependency upon it for those platforms without a native port of iconv. H But nothing precludes us from rolling up apr and dropping it upon the world, then rolling up apr-util and dropping that 1.0.0 in a separate step. Sorry but that's a REALLY horrible precedent to set. Yeah APR is 1.0 but apr-util isn't... I agree there is no need to tie the versioning, but I think for the initial release of a major number they should be, so apr 2.0 and apr-util 2.0 should also be tied and released on the same date, whereas apr-util 1.1 can go out anytime. If people want to veto the candidate and force a retag with new code then that's one thing. when I roll 1.0 it'll be all 3 repo's at the same time, as will RC2. snip Why does this hold up an apr-util 1.0 ? Please elaborate further. Because apr-util 1.0 consumes apr-iconv, at least for non-unix distros. It does slightly annoy me that there has been a decent sized interval to discsuss such issues and only now are they being brought up. Agreed - wish there were more eyes on the code. My attention was solely focused on apr for the past weeks. I think we very nearly have that right, so now i'm looking sideways at apr-util and how it could defy developer's expectations. And the build breakage pointed out to me how wonky the current apr-iconv API really was (and mostly, my fault in the first place :) Sorry you haven't had enough time (I know you've been busy), but there aren't any votes for/against this and we (I) imposed a deadline to avoid exactly this sort of drawn out delay. If the answer to the question does what we have now work is yes then apr-util 1.0 is good to go. Sorry, but eventually you have to make a decision. I haven't seen anyone state that what we have doesn't work, so I see no reason to hold things up for yet another code tweak at the 11th hour. david
