Re: crypt_r versus macosx
On Thursday 06 September 2012, Benson Margulies wrote: I'm trying to build httpd 2.4.3 on OSX Mountain Lion with mod_session_crypto. I'm failing. I think that the reason is the following error from the configure process for apr-util: configure:36291: checking for crypt_r configure:36291: gcc -o conftest -g -O2 -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp conftest.c 5 Undefined symbols for architecture x86_64: _crypt_r, referenced from: _main in cc3WYSLM.o Sure enough, no such API on osx. Am I out of luck? No, configure should then continue without crypt_r support. Does configure abort after this check? If so, can you post more of its output? E.g. the last 100 lines before it aborts?
Re: apr_dbd_freetds
On Wednesday 22 August 2012, Graham Leggett wrote: On 22 Aug 2012, at 7:18 PM, Nick Kew wrote: PR 53666 tells us apr_dbd_freetds doesn't work with Sybase, and very probably never did. The reporter attaches a patch, but it's one I'm not happy with, even if I had access to any FreeTDS backend to test-drive (which I don't). The basic objection is that FreeTDS doesn't support prepared statements, and the emulation in the driver opens big security issues. We've had a bit of a thread on the subject on dev@httpd. Is anyone in a position to take up the baton on FreeTDS? If not, perhaps it's time we dropped that driver in favour of the ODBC one. Am I right in understanding that a user of the freetds driver could realistically use the ODBC driver instead? (I am assuming this is Windows). If so, I would be in favour of deprecating the freetds driver and dropping the driver in v2.0, as a driver that doesn't support prepared statements suffers higher security risks. I think the FreeTDS driver should either emulate prepared statements by using a known secure escaping function from FreeTDS. If that does not exist, it should be removed. Also, apr_dbd_escape currently returns the unchanged string for FreeTDS. I would be more comfortable if it returned NULL (or if there was a way to return ENOTIMPL).
Re: apu-util DBD back-ends
On Thursday 16 August 2012, olli hauer wrote: My my intention comes from the FreeBSD ports system. We do not use the bundled apr/apr-util from apache, there we use apr / apr-util as own port. (Perhaps with apr-1.4.6 and apr-util-1.5 in a view weeks). This separation allows us to use an actual apr/apr-util and the user to build apr with different backends, but then we do not have enough information in the apache port to construct build params and dependency lists ... I don't understand what problem you are trying to solve. The apache port should not need any different build params or dependency lists depending on which dbd backends are available. Having a dependency on the apr-util port and calling apu-1-config should be enough. Or do you have to list all of apr-util's dependencies in the apache port, too? As workaround I can implement this together with a function which lists DBD backends as local patch but I prefer upstream support. If there is interest I can spend some more time to extend apr/apr-util.
[VOTE] Release apr-util 1.5.1
Hi, here comes the next try. Tarballs/zipfiles are at http://apr.apache.org/dev/dist/ Full CHANGES are here: http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5 http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.1 +/-1 [ ] Release apr-util 1.5.1 as GA
Re: [VOTE] Release apr-util 1.5.1
[ +1 ] Release apr-util 1.5.1 as GA I see no new issues, just the stuff I had mentioned on 1.5.0. The warning was not an issue, I should not have even mentioned it. Again, the win32 sources are missing .mak/.dep files. These have always been part of the windows source packages until quietly dropped in 1.4. IIRC I saw mention of getting these into svn, not sure where that discussion went. Might as well drop the win32 packages until they do, we can always run lineends on the unix source and have what the windows source packages are currently giving us as people expect these files in the win32 source. One issue I did not mention during 1.5.0 was that testlib would not build but I did not have time to dig into it. One reason is testall is not being linked to xml.lib, so it throws a lot of unresolved external symbol errors out. It also does not get linked to apriconv-1.lib so xlate causes more unresolved external symbol errors. I'm not sure if this has been broken in past versions or not, I would think it has. This takes care of these for 1.5.next until the currently included expat is removed (I saw mention of this recently); --- test/makefile.win 2012-09-07 18:43:04.27220 -0700 +++ test/makefile.win 2012-09-07 17:55:09.08120 -0700 @@ -88,7 +88,9 @@ !IF $(MODEL) == static PROGRAM_DEPENDENCIES = \ $(APR_PATH)\$(APROUTDIR)\apr-1.lib \ - ..\$(OUTDIR)\aprutil-1.lib + $(API_PATH)\$(APROUTDIR)\apriconv-1.lib \ + ..\$(OUTDIR)\aprutil-1.lib \ + ..\xml\expat\lib\$(OUTDIR)\xml.lib STATIC_CFLAGS = /D APR_DECLARE_STATIC /D APU_DECLARE_STATIC STATIC_LIBS = odbc32.lib odbccp32.lib wldap32.lib !ELSE Testing: testxlate : Line 63: expected0, but saw22 FAILED 1 of 1 testreslist : Line 255: expected10, but saw20 FAILED 1 of 1 I do not believe these are a regression however IIRC. I see no reason to not release 1.5.1. Regards, Gregg
