Any objections to committing cmake builds for Windows to the stable branches?

[Jeff Trawick]

With something easily visible like README.cmake containing appropriate
disclaimers?*

I suspect that build bugs are likely to be found more quickly with the
stable branches just because it fits into more applications and/or
workflows (i.e., more people).

*i.e., probably has bugs in the build, has known limitations (see list),
build interface may change in a future stable release (until it is no
longer experimental), etc.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

On Thu, Aug 22, 2013 at 6:47 PM, Tom Donovan wrote:

> On 08/22/2013 04:55 PM, Jeff Trawick wrote:
> > On Thu, Aug 22, 2013 at 10:49 AM, Tom Donovan  > <mailto:donov...@bellatlantic.net>> wrote:
> >
> > On 08/20/2013 03:47 PM, Jeff Trawick wrote:
> > > I plan to spend some time tilting at that windmill starting later
> this week, for the purposes of
> > > getting a flexible build on Windows.  Enough time to get something
> working?  Dunno :(
> > >
> > > --
> > > Born in Roswell... married an alien...
> > > http://emptyhammock.com/
> >
> > I gave it a try last March, but I never found the time to follow up
> and finish it.
> > I was able to build apr and httpd (trunk) on Windows7.
> >
> > My Windows-only CMakeLists.txt files for both apr & httpd, along
> with some notes, are at:
> >
> >http://people.apache.org/~tdonovan/cmake/HTTPD_CMake.zip
> >
> > Please help yourself to anything here which is useful to your effort.
> >
> > -t-
> >
> >
> > Hi Tom,
> >
> > By chance did you experiment with FindOpenSSL, FindZLIB, etc.?
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
> Hi Jeff,
>
> I looked at them briefly, but no, I didn't experiment much.
>
> On Windows, those CMake modules seem to have an impossible job.  There is
> really no "standard"
> location on Windows for OpenSSL, Zlib, et. al. - especially since headers
> are needed in addition to
> the runtime libraries.   These modules pose a risk of finding some
> unrelated OpenSSL or Zlib library
> which might have been built with a different Windows compiler, and might
> use a different C runtime
> library.
>
> I used my own rules instead to locate the eleven prerequisites that APR or
> HTTPD might use on
> Windows.  The rules I made for PCRE, ICONV, LUA, LIBXML2 (or EXPAT), ZLIB,
> OPENSSL, SQLITE3, PGSQL,
> MYSQL, ORACLE, and BDB (Berkeley DB) were:
>
> *  If the symbol is defined on the CMake command-line, it points to the
> directory that the
> prerequisite is installed in.  i.e. the directory containing bin, include,
> and lib subdirectories.
>
> e.g.
> CMAKE -D SQLITE3=C:/work/sqlite3 -D PCRE=D:/build/pcre  -D
> ICONV=C:/work/libiconv ...
>
> *  If the symbol is not defined, a check is made for directories named:
>
> srclib\pcre, srclib\libiconv, srclib\lua, srclib\libxml2, srclib\zlib,
> srclib\openssl,
> srclib\sqlite3, srclib\postgresql, srclib\mysql, srclib\oracle, or
> srclib\berkeleydb.
>
> *  If the symbol isn't defined and the srclib\XXX subdirectory doesn't
> exist - then the
> prerequisite is not present.
>
> -tom-
>
>
Thanks...

I haven't gotten nearly far enough with optional prerequisites to judge
FindXXX vs. custom logic.  For now, this setting before starting cmake has
been enough to allow FindExpat and FindLibXml2 to work:

set
CMAKE_LIBRARY_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\lib;c:\Users\Trawick\Expat2.1.0\Bin;
set
CMAKE_INCLUDE_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\include;c:\Users\Trawick\Expat2.1.0\Source\lib

I'll see how far that gets me :)

Another difference in my direction, tied up in the same cmake logic, is not
copying some other project's DLLs around, such as into the apr (or httpd
for that matter) install directory.  Theoretically it should just work by
choosing the same install prefix for each project.  Otherwise the user
would have to update PATH.  I fear that the magic to avoid that hides the
steps that might be necessary when they later update one particular support
library.

A bundler that delivers a complete application package and can't get the
cmake install logic in all the support library packages to agree would just
copy the DLLs to the desired place in their own scripts.

Either of these choices may fall by the wayside because of what lurks right
around the corner.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

On Thu, Aug 22, 2013 at 10:49 AM, Tom Donovan wrote:

> On 08/20/2013 03:47 PM, Jeff Trawick wrote:
> > I plan to spend some time tilting at that windmill starting later this
> week, for the purposes of
> > getting a flexible build on Windows.  Enough time to get something
> working?  Dunno :(
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
> I gave it a try last March, but I never found the time to follow up and
> finish it.
> I was able to build apr and httpd (trunk) on Windows7.
>
> My Windows-only CMakeLists.txt files for both apr & httpd, along with some
> notes, are at:
>
>http://people.apache.org/~tdonovan/cmake/HTTPD_CMake.zip
>
> Please help yourself to anything here which is useful to your effort.
>
> -t-
>

Hi Tom,

By chance did you experiment with FindOpenSSL, FindZLIB, etc.?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1516542 - in /apr/apr/trunk: CHANGES CMakeLists.txt include/apr.hwc

[Jeff Trawick]

On Thu, Aug 22, 2013 at 3:22 PM,  wrote:

> Author: trawick
> Date: Thu Aug 22 19:22:03 2013
> New Revision: 1516542
>
> URL: http://svn.apache.org/r1516542
> Log:
> Add experimental cmake-based build system for Windows.
>
> include/apr.hwc is almost exactly the same as apr.hw; it uses
> variables for cmake-time feature selection so that cmake
> can easily generate apr.h.
>
> Added:
> apr/apr/trunk/CMakeLists.txt   (with props)
> apr/apr/trunk/include/apr.hwc   (with props)
> Modified:
> apr/apr/trunk/CHANGES
>
> Modified: apr/apr/trunk/CHANGES
> URL:
> http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?rev=1516542&r1=1516541&r2=1516542&view=diff
>
> ==
> --- apr/apr/trunk/CHANGES [utf-8] (original)
> +++ apr/apr/trunk/CHANGES [utf-8] Thu Aug 22 19:22:03 2013
> @@ -1,6 +1,8 @@
>   -*- coding: utf-8 -*-
>  Changes for APR 2.0.0
>
> +  *) Add experimental cmake-based build system for Windows.  [Jeff
> Trawick]
> +
>
>
Note the list of current bugs/deficiencies in CMakeLists.txt, a lot of
which are handled by Tom's CMakeLists.txt which he posted a couple of hours
ago.  I plan to pull in his stuff as I can understand/test it, but feel
free to pitch in :)

>From CMakeLists.txt:

# . Fix problem where srcdir/include/apr.h (if it exists) is found before
builddir/apr.h
#   (and similar for apu_want.h)
# . Document example 32-bit and 64-bit Windows builds using NMake
# . Build and optionally run gen_test_char
# . Build apr_app.c into libapr-2 properly (what about apr-2.lib?)
# . Options for remaining features, along with finding any necessary
libraries
#   + APR_POOL_DEBUG
#   + APU_DSO_MODULE_BUILD
#   + APU_HAVE_GDBM
#   + APU_HAVE_NDBM
#   + APU_HAVE_DB
#   + APU_HAVE_PGSQL
#   + APU_HAVE_MYSQL
#   + APU_HAVE_SQLITE3
#   + APU_HAVE_SQLITE2
#   + APU_HAVE_ORACLE
#   + APU_HAVE_ODBC
#   + APU_HAVE_CRYPTO
#   + APU_HAVE_OPENSSL
#   + APU_HAVE_NSS
#   + APU_HAVE_COMMONCRYPTO
#   + APU_HAVE_ICONV
#   + APU_USE_LIBXML2 (sketched in, but not working)
# . Support static *or* shared build of Expat
# . Some easier way to run the test suite (not just testall.exe)
# . All the other stuff Jeff doesn't know about yet

If anyone cares about this, the best way to help in the very short term is
to add stuff you know of that I've missed from the bug/missing-feature
list.  Then, of course, pull up your shirt sleeves and pitch in.

Apologies for the programming style in CMakeLists.txt, which is a lot
different than the one Tom had; if you've ever seen the one distributed
with PCRE you might guess (correctly) that I had mainly looked at that one
before starting this one for APR.

I suggest the following as the roadmap for Windows build support:

APR Trunk/2.0:

As soon as multiple developers can use cmake successfully and build bugs
have been resolved, axe any support for specific MS compilers/IDEs/whatever.

(autoconf-/MinGW-based build support remains; I happen to feel very
productive using that for development/debugging, though I don't see enough
interest to finish the work to fully support that for end user builds; no
knowledge here of autoconf-Cygwin-based build support for Windows other
than that there are various pieces of configure code to support that)

Current stable branches of apr 1.x/apr-util 1.x:

Add cmake-based build support as an additional option "before long."

apr-iconv?  I'd rather not think about that for now.  (Somebody remind me
which httpd features need that on Windows and maybe I'll be motivated.)

Implied or required layout of projects:

Traditional builds of httpd/apr*/etc. typically put ASF and other support
libraries in the tree under httpd/srclib, and in fact some unexpected
httpd+Windows dependencies on apr essentially required that.  I haven't
figured out yet if any of that is baked into Tom's cmake work for
apr/httpd, or if srclib/ is simply the default.  I have ZERO
interest in touching such a setup personally, and at present the apr
install will set up private_include/ alongside include/ to work around the
httpd desire for such files.  (I guess there are any number of other
dependencies I don't know about/remember :()

Thanks in advance for the *.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

On Thu, Aug 22, 2013 at 10:49 AM, Tom Donovan wrote:

> On 08/20/2013 03:47 PM, Jeff Trawick wrote:
> > I plan to spend some time tilting at that windmill starting later this
> week, for the purposes of
> > getting a flexible build on Windows.  Enough time to get something
> working?  Dunno :(
> >
> > --
> > Born in Roswell... married an alien...
> > http://emptyhammock.com/
>
> I gave it a try last March, but I never found the time to follow up and
> finish it.
> I was able to build apr and httpd (trunk) on Windows7.
>
> My Windows-only CMakeLists.txt files for both apr & httpd, along with some
> notes, are at:
>
>http://people.apache.org/~tdonovan/cmake/HTTPD_CMake.zip
>
> Please help yourself to anything here which is useful to your effort.
>
> -t-
>

Wow, you got pretty darn far!  (too bad you didn't go ahead and commit ;) )

I currently anticipate

* fixing a few basic issues in what I have "soon" and then committing
* subsequently pulling in chunks of your stuff as I understand it/can try
it out

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: rough, initial cmake build for apr trunk

[Jeff Trawick]

On Thu, Aug 22, 2013 at 8:44 AM, Jeff Trawick  wrote:

> On Wed, Aug 21, 2013 at 5:51 PM, Jeff Trawick  wrote:
>
>> This is barely enough to run testapr.  For now it is intended only for
>> Windows.  include/apr.hwc is just apr.hw with variables for
>> APR_HAS_EXPAT|LIBXML2.  (And sorry about that mixed LF/CR-LF patch.)
>>
>>
> Maybe this is only funny to me but...
>
> I did some further work to build an apr shared library...  I started a
> cmake spec for httpd to use that.  httpd.exe displayed the output of
> gen_test_char on every invocation  As I had just spent some time getting
> gen_test_char to work at the right point in the httpd built to produce
> test_char.h I assumed there was some confusion about the build there.
>  Couldn't find anything.  Created separate project consisting of
> essentially an apr_socket_create().  Ran that, got the gen_test_char
> output.  Why?  apr trunk has gen_test_char.c too (with main(), of course),
> and I had it in the list of files to build libapr.
>
>
Ahh, that's better:

C:\Users\Trawick\httpdbuild>.\httpd -V
Server version: Apache/2.5.0-dev (Win32)
Server built:   Aug 22 2013 09:03:20
Server's Module Magic Number: 20130702:3
Server loaded:  APR 2.0.0-dev
Compiled using: APR 2.0.0-dev
Architecture:   32-bit
Server MPM: WinNT
  threaded: yes (fixed thread count)
forked: no
Server compiled with
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SUEXEC_BIN="/apache/bin/suexec"
 -D DEFAULT_PIDLOG="httpd.pid"
 -D DEFAULT_SCOREBOARD="apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error.log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

Only about a million things left to handle...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: rough, initial cmake build for apr trunk

[Jeff Trawick]

On Wed, Aug 21, 2013 at 5:51 PM, Jeff Trawick  wrote:

> This is barely enough to run testapr.  For now it is intended only for
> Windows.  include/apr.hwc is just apr.hw with variables for
> APR_HAS_EXPAT|LIBXML2.  (And sorry about that mixed LF/CR-LF patch.)
>
>
Maybe this is only funny to me but...

I did some further work to build an apr shared library...  I started a
cmake spec for httpd to use that.  httpd.exe displayed the output of
gen_test_char on every invocation  As I had just spent some time getting
gen_test_char to work at the right point in the httpd built to produce
test_char.h I assumed there was some confusion about the build there.
 Couldn't find anything.  Created separate project consisting of
essentially an apr_socket_create().  Ran that, got the gen_test_char
output.  Why?  apr trunk has gen_test_char.c too (with main(), of course),
and I had it in the list of files to build libapr.

Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

On Wed, Aug 21, 2013 at 3:49 PM, William A. Rowe Jr. wrote:

> On Tue, 20 Aug 2013 15:47:46 -0400
> Jeff Trawick  wrote:
>
> > I plan to spend some time tilting at that windmill starting later this
> > week, for the purposes of getting a flexible build on Windows.
> > Enough time to get something working?  Dunno :(
>
> Just FYI, RELWITHDEBINFO was a broken model, but that's the model we
> have always aimed for with separate .pdb symbol files for win builds.
> We want several things that the attached patch to cmake 2.8.7 addresses
> (it isn't the most elegant, but it works);
>
> * disable stack corruption^Woptimization so that user crash dumps
>   with no debug info are still nominally decipherable
>
> * a release build is *never* incremental (duh)
>
> * /opt:ref to toss useless/unreferenced debug leftovers for release
>
> * there was a stupid bug where shared lib link flags in RELWITHDEBINFO
>   inherited DEBUG model, not RELWITHDEBINFO model from exe link flags.
>
> I've never worked out how to propagate the actual .pdb file into the
> install lib/ or bin/ dir when performing the .exe / .dll install step.
> Hints on improving the patch would be great.
>
>
>
I guess all of this necessarily goes in the cmake backend, but possibly
with a knob in the APR spec to turn it on?


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

rough, initial cmake build for apr trunk

[Jeff Trawick]

This is barely enough to run testapr.  For now it is intended only for
Windows.  include/apr.hwc is just apr.hw with variables for
APR_HAS_EXPAT|LIBXML2.  (And sorry about that mixed LF/CR-LF patch.)

I point to the latest Windows binary installs of libxml2 and expat like
this:

set
CMAKE_LIBRARY_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\lib;c:\Users\Trawick\Expat2.1.0\Bin;
set
CMAKE_INCLUDE_PATH=c:\Users\Trawick\libxml2-2.7.8.win32\include;c:\Users\Trawick\Expat2.1.0\Source\lib

and I've only used the nmake backend (from a VS 2010 prompt).

I haven't actually tried very hard to use libxml2; the build I have seems
to want a GNU iconv??  More work would be required to use that.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: CMakeLists.txt
===
--- CMakeLists.txt  (revision 0)
+++ CMakeLists.txt  (working copy)
@@ -0,0 +1,342 @@
+PROJECT(APR C)
+
+CMAKE_MINIMUM_REQUIRED(VERSION 2.8.6)
+
+INCLUDE(GenerateExportHeader)
+
+# Either Expat or LibXml2 is required
+FIND_PACKAGE(Expat)
+FIND_PACKAGE(LibXml2)
+
+IF(NOT EXPAT_FOUND AND NOT LIBXML2_FOUND)
+  MESSAGE(FATAL_ERROR "Either Expat or LibXml2 is required, but neither was 
found")
+ENDIF()
+
+IF(EXPAT_FOUND)
+  OPTION(APR_USE_EXPAT  "Use Expat"ON)
+  IF(LIBXML2_FOUND)
+OPTION(APR_USE_LIBXML2  "Use LibXml2"  OFF)
+  ENDIF()
+ELSE()
+  OPTION(APR_USE_LIBXML2"Use LibXml2"  ON)
+ENDIF()
+
+OPTION(APR_SHOW_SETTINGS"Show the build configuration" ON)
+OPTION(APR_BUILD_TESTAPR"Build the test suite" OFF)
+
+IF(NOT APR_USE_EXPAT AND NOT APR_USE_LIBXML2)
+  MESSAGE(FATAL_ERROR "Either Expat or LibXml2 must be selected")
+ENDIF()
+IF(APR_USE_EXPAT AND APR_USE_LIBXML2)
+  MESSAGE(FATAL_ERROR "Only one of Expat and LibXml2 can be selected")
+ENDIF()
+IF(APR_USE_EXPAT)
+  SET(apr_use_expat_10 1)
+  SET(apr_use_libxml2_10 0)
+ELSE()
+  SET(apr_use_expat_10 0)
+  SET(apr_use_libxml2_10 1)
+ENDIF()
+
+CONFIGURE_FILE(include/apr.hwc
+   ${PROJECT_BINARY_DIR}/apr.h)
+
+IF(APR_USE_EXPAT)
+  SET(XMLLIB_INCLUDE_DIR ${EXPAT_INCLUDE_DIRS})
+  SET(XMLLIB_LIBRARIES   ${EXPAT_LIBRARIES})
+ELSE()
+  SET(XMLLIB_INCLUDE_DIR ${LIBXML2_INCLUDE_DIR})
+  SET(XMLLIB_LIBRARIES   ${LIBXML2_LIBRARIES})
+ENDIF()
+
+# BROKEN: not searching PROJECT_BINARY_DIR first, so I have to
+# manually delete apr.h in PROJECT_SOURCE_DIR/include if
+# I've generated apr.h before using a Unix-style build
+INCLUDE_DIRECTORIES(${PROJECT_BINARY_DIR} ${PROJECT_SOURCE_DIR}/include 
${PROJECT_SOURCE_DIR}/include/private ${PROJECT_SOURCE_DIR}/include/arch/win32 
${PROJECT_SOURCE_DIR}/include/private ${PROJECT_SOURCE_DIR}/include/arch/unix 
${XMLLIB_INCLUDE_DIR})
+
+ADD_DEFINITIONS(-DAPR_DECLARE_EXPORT)
+
+SET(APR_HEADERS ${PROJECT_BINARY_DIR}/apr.h)
+
+SET(APR_SOURCES
+  exports.c
+  export_vars.c
+  atomic/win32/apr_atomic.c
+  buckets/apr_brigade.c
+  buckets/apr_buckets.c
+  buckets/apr_buckets_alloc.c
+  buckets/apr_buckets_eos.c
+  buckets/apr_buckets_file.c
+  buckets/apr_buckets_flush.c
+  buckets/apr_buckets_heap.c
+  buckets/apr_buckets_mmap.c
+  buckets/apr_buckets_pipe.c
+  buckets/apr_buckets_pool.c
+  buckets/apr_buckets_refcount.c
+  buckets/apr_buckets_simple.c
+  buckets/apr_buckets_socket.c
+  crypto/apr_crypto.c
+  crypto/apr_crypto_commoncrypto.c
+  crypto/apr_crypto_nss.c
+  crypto/apr_crypto_openssl.c
+  crypto/apr_md4.c
+  crypto/apr_md5.c
+  crypto/apr_passwd.c
+  crypto/apr_sha1.c
+  crypto/crypt_blowfish.c
+  crypto/getuuid.c
+  crypto/uuid.c
+  dbd/apr_dbd.c
+  dbd/apr_dbd_mysql.c
+  dbd/apr_dbd_odbc.c
+  dbd/apr_dbd_oracle.c
+  dbd/apr_dbd_pgsql.c
+  dbd/apr_dbd_sqlite2.c
+  dbd/apr_dbd_sqlite3.c
+  dbd/unsupported/apr_dbd_freetds.c
+  dbm/apr_dbm.c
+  dbm/apr_dbm_berkeleydb.c
+  dbm/apr_dbm_gdbm.c
+  dbm/apr_dbm_ndbm.c
+  dbm/apr_dbm_sdbm.c
+  dbm/sdbm/sdbm.c
+  dbm/sdbm/sdbm_hash.c
+  dbm/sdbm/sdbm_lock.c
+  dbm/sdbm/sdbm_pair.c
+  dso/win32/dso.c
+  encoding/apr_base64.c
+  encoding/apr_escape.c
+  file_io/unix/copy.c
+  file_io/unix/fileacc.c
+  file_io/unix/filepath_util.c
+  file_io/unix/fullrw.c
+  file_io/unix/mktemp.c
+  file_io/unix/tempdir.c
+  file_io/win32/buffer.c
+  file_io/win32/dir.c
+  file_io/win32/filedup.c
+  file_io/win32/filepath.c
+  file_io/win32/filestat.c
+  file_io/win32/filesys.c
+  file_io/win32/flock.c
+  file_io/win32/open.c
+  file_io/win32/pipe.c
+  file_io/win32/readwrite.c
+  file_io/win32/seek.c
+  hooks/apr_hooks.c
+  locks/win32/proc_mutex.c
+  locks/win32/thread_cond.c
+  locks/win32/thread_mutex.c
+  locks/win32/thread_rwlock.c
+  memcache/apr_memcache.c
+  memory/unix/apr_pools.c
+  misc/unix/errorcodes.c
+  misc/unix/getopt.c
+  misc/unix/otherchild.c
+  misc/unix/version.c
+  misc/win32/apr_app.c
+  misc/win32/charset.c
+  misc/win32/env.c
+  misc/win32/internal.c
+  misc/win32/misc.c
+  misc/win32/rand.c
+  misc/win32/start.c
+  misc/win32/utf8.c

Re: Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

On Tue, Aug 20, 2013 at 10:12 PM, William A. Rowe Jr.
wrote:

> On Tue, 20 Aug 2013 15:47:46 -0400
> Jeff Trawick  wrote:
>
> > I plan to spend some time tilting at that windmill starting later this
> > week, for the purposes of getting a flexible build on Windows.
> > Enough time to get something working?  Dunno :(
>
> Feel free to attack it from either angle, once we have a unix or
> a windows starting point, the rest is straightforward.
>
> I've looked some at what it will take.  Was going to use what the
> pcre project has done as a starting point.
>

Yeah.  I had looked at that very briefly before, but after staring at that
some more today and spending a couple of hours starting a spec for APR
trunk, I'm very happy with my progress.  I hope to have the core library
and test suite building today.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Did anybody ever play with cmake+apr and/or have any advice applicable to cmake+apr?

[Jeff Trawick]

I plan to spend some time tilting at that windmill starting later this
week, for the purposes of getting a flexible build on Windows.  Enough time
to get something working?  Dunno :(

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1502807 - in /apr/apr/branches/1.4.x: ./ build/apr_network.m4

[Jeff Trawick]

On Sat, Jul 13, 2013 at 11:54 AM,  wrote:

> Author: rjung
> Date: Sat Jul 13 15:54:54 2013
> New Revision: 1502807
>
> URL: http://svn.apache.org/r1502807
> Log:
> Fix broken test for O_NONBLOCK inheritance.
>
> Followup to r1449570 resp. r1449569 (1.5.x)
> resp. r1449568 (trunk) which miss the variable
> declaration.
>
> Backport of r1502804 from trunk resp. r1502805
> (1.5.x).
>

need CHANGES entry to describe regression in 1.4.8


>
> Modified:
> apr/apr/branches/1.4.x/   (props changed)
> apr/apr/branches/1.4.x/build/apr_network.m4
>
> Propchange: apr/apr/branches/1.4.x/
>
> --
>   Merged /apr/apr/trunk:r1502804
>
> Modified: apr/apr/branches/1.4.x/build/apr_network.m4
> URL:
> http://svn.apache.org/viewvc/apr/apr/branches/1.4.x/build/apr_network.m4?rev=1502807&r1=1502806&r2=1502807&view=diff
>
> ==
> --- apr/apr/branches/1.4.x/build/apr_network.m4 (original)
> +++ apr/apr/branches/1.4.x/build/apr_network.m4 Sat Jul 13 15:54:54 2013
> @@ -570,6 +570,9 @@ AC_DEFUN([APR_CHECK_O_NONBLOCK_INHERITED
>  #ifdef HAVE_SYS_SOCKET_H
>  #include 
>  #endif
> +#ifdef HAVE_SYS_TIME_H
> +#include 
> +#endif
>  #ifdef HAVE_SYS_SELECT_H
>  #include 
>  #endif
> @@ -590,6 +593,8 @@ int main(void) {
>  int listen_port, rc;
>  struct sockaddr_in sa;
>  socklen_t sa_len;
> +fd_set fds;
> +struct timeval tv;
>
>  listen_s = socket(AF_INET, SOCK_STREAM, 0);
>  if (listen_s < 0) {
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: missing DAPU_DECLARE_EXPORT flag

[Jeff Trawick]

On Mon, Jul 8, 2013 at 11:35 AM, Ervin Bajramovic wrote:

> apr-1.4.8 and apr-util-1.5.2
>

Thanks for confirming.

Use your build hack or use the apr-1.5.x branch (unreleased, has as few
minor features over 1.4.x).

To get a real fix, either we need to release apr-1.5.0 (to pick up a few
minor features including shared library support on MinGW) or we need to get
the MinGW changes into apr-1.4.next.


> 
>
> ** **
>
> *Von:* Jeff Trawick [mailto:traw...@gmail.com]
> *Gesendet:* Montag, 8. Juli 2013 17:10
> *An:* Ervin Bajramovic
> *Cc:* APR Developer List
> *Betreff:* Re: missing DAPU_DECLARE_EXPORT flag
>
> ** **
>
> On Mon, Jul 8, 2013 at 11:06 AM, Ervin Bajramovic 
> wrote:
>
> Hi All
>
>  
>
> I tried to build apr-util on a windows xp and windows 7 pc with mingw but
> it faild on both pcs with this error message:
>
> ** **
>
> What level of APR?  What level of APR-Util?
>
> ** **
>
> IIRC some support for shared MinGW builds that affects APR-Util is in APR
> 1.5.x (unreleased) but not APR 1.4.x.
>
>  
>
>  
>
> make
>
> Making all in xml/expat
>
> make[1]: Entering directory `/src/apr-util/xml/expat'
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmltok.lo -c lib/xmltok.c
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c
>
> /bin/sh ./libtool --silent --mode=link gcc -g -O2 -DHAVE_EXPAT_CONFIG_H
> -I./li
>
> b -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/apr/lib  -o
> libexpat.l
>
> a lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
>
> make[1]: Leaving directory `/src/apr-util/xml/expat'
>
> make[1]: Entering directory `/src/apr-util'
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_brigade.lo -c buckets/apr_brigade.c &&
> touch buc
>
> kets/apr_brigade.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets.lo -c buckets/apr_buckets.c &&
> touch buc
>
> kets/apr_buckets.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets_alloc.lo -c
> buckets/apr_buckets_alloc.c
>
> && touch buckets/apr_buckets_alloc.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets_eos.lo -c
> buckets/apr_buckets_eos.c && t
>
> ouch buckets/apr_buckets_eos.lo
>
> buckets/apr_buckets_eos.c:47:42: error: variable 'apr_bucket_type_eos'
> definitio
>
> n is marked dllimport
>
> buckets/apr_buckets_eos.c:47:42: warning: 'apr_bucket_type_eos' redeclared
> witho
>
> ut dllimport attribute after being referenced with dll linkage [enabled by
> defau
>
> lt]
>
> make[1]: *** [buckets/apr_buckets_eos.lo] Error 1
>
> make[1]: Leaving directory `/src/apr-util'
>
> make: *** [all-recursive] Error 1
>
>  
>
> I could fix the problem with some help of a friend. Adding the flag
> -DAPU_DECLARE_EXPORT on line 54 in the file build/rules.mk fix the
> apr-util build problem.
>
>  
>
> Regards Ervin
>
>
>
> 
>
> ** **
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: missing DAPU_DECLARE_EXPORT flag

[Jeff Trawick]

On Mon, Jul 8, 2013 at 11:06 AM, Ervin Bajramovic wrote:

> Hi All
>
> ** **
>
> I tried to build apr-util on a windows xp and windows 7 pc with mingw but
> it faild on both pcs with this error message:
>

What level of APR?  What level of APR-Util?

IIRC some support for shared MinGW builds that affects APR-Util is in APR
1.5.x (unreleased) but not APR 1.4.x.


> 
>
> ** **
>
> make
>
> Making all in xml/expat
>
> make[1]: Entering directory `/src/apr-util/xml/expat'
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmlparse.lo -c lib/xmlparse.c
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmltok.lo -c lib/xmltok.c
>
> /bin/sh ./libtool --silent --mode=compile gcc -g -O2
> -DHAVE_EXPAT_CONFIG_H   -I.
>
> /lib -I. -o lib/xmlrole.lo -c lib/xmlrole.c
>
> /bin/sh ./libtool --silent --mode=link gcc -g -O2 -DHAVE_EXPAT_CONFIG_H
> -I./li
>
> b -I. -no-undefined -version-info 5:0:5 -rpath /usr/local/apr/lib  -o
> libexpat.l
>
> a lib/xmlparse.lo lib/xmltok.lo lib/xmlrole.lo
>
> make[1]: Leaving directory `/src/apr-util/xml/expat'
>
> make[1]: Entering directory `/src/apr-util'
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_brigade.lo -c buckets/apr_brigade.c &&
> touch buc
>
> kets/apr_brigade.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets.lo -c buckets/apr_buckets.c &&
> touch buc
>
> kets/apr_buckets.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets_alloc.lo -c
> buckets/apr_buckets_alloc.c
>
> && touch buckets/apr_buckets_alloc.lo
>
> /bin/sh /usr/local/apr/build-1/libtool --silent --mode=compile gcc -g
> -O2   -DHA
>
> VE_CONFIG_H -DWIN32 -D__MSVCRT__ -D_LARGEFILE64_SOURCE
> -I/src/apr-util/include
>
> -I/src/apr-util/include/private  -I/usr/local/apr/include/apr-1
> -I/src/apr-uti
>
> l/xml/expat/lib  -o buckets/apr_buckets_eos.lo -c
> buckets/apr_buckets_eos.c && t
>
> ouch buckets/apr_buckets_eos.lo
>
> buckets/apr_buckets_eos.c:47:42: error: variable 'apr_bucket_type_eos'
> definitio
>
> n is marked dllimport
>
> buckets/apr_buckets_eos.c:47:42: warning: 'apr_bucket_type_eos' redeclared
> witho
>
> ut dllimport attribute after being referenced with dll linkage [enabled by
> defau
>
> lt]
>
> make[1]: *** [buckets/apr_buckets_eos.lo] Error 1
>
> make[1]: Leaving directory `/src/apr-util'
>
> make: *** [all-recursive] Error 1
>
> ** **
>
> I could fix the problem with some help of a friend. Adding the flag
> -DAPU_DECLARE_EXPORT on line 54 in the file build/rules.mk fix the
> apr-util build problem.
>
> ** **
>
> Regards Ervin
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Apache Portable Runtime library 1.4.8 Released

[Jeff Trawick]

   The Apache Software Foundation and the Apache Portable Runtime
   Project are proud to announce the General Availability of version
   1.4.8 of the APR Apache Portable Runtime library.

   APR 1.4.8 provides fixes for a number of bugs present in the
   previous release, 1.4.6.  We are grateful to the many members of
   the user community who contributed to this release.

   (See CHANGES-APR-1.4 for more information.)

   Apache Portable Runtime Utility library 1.5.2 remains current.

   Version 1.2.1 of the companion APR-iconv library, an alternative
   portable implementation of the 'iconv' library, remains current.

   APR is available for download from:

 http://apr.apache.org/download.cgi

   The mission of the Apache Portable Runtime Project is to create
   and maintain software libraries that provide a predictable and
   consistent interface to underlying platform-specific
   implementations. The primary goal is to provide an API to
   which software developers may code and be assured of predictable
   if not identical behavior regardless of the platform on which
   their software is built, relieving them of the need to code
   special-case conditions to work around or take advantage of
   platform-specific deficiencies or features.

   APR and its companion libraries are implemented entirely in C
   and provide a common programming interface across a wide variety
   of operating system platforms without sacrificing performance.
   Currently supported platforms include:

 UNIX variants
 Windows
 Netware
 Mac OS X
 OS/2

   To give a brief overview, the primary core
   subsystems of APR 1.x include the following:

 Atomic operations
 Dynamic Shared Object loading
 File I/O
 Locks (mutexes, condition variables, etc)
 Memory management (high performance allocators)
 Memory-mapped files
 Multicast Sockets
 Network I/O
 Shared memory
 Thread and Process management
 Various data structures (tables, hashes, priority queues, etc)

   For a more complete list, please refer to the following URLs:

 http://apr.apache.org/docs/apr/modules.html
 http://apr.apache.org/docs/apr-util/modules.html

   Users of APR 0.9 should be aware that migrating to the APR 1.x
   programming interfaces may require some adjustments; APR 1.x is
   neither source nor binary compatible with earlier APR 0.9 releases.
   Users of APR 1.x can expect consistent interfaces and binary backwards
   compatibility throughout the entire APR 1.x release cycle, as defined
   in our versioning rules:

 http://apr.apache.org/versioning.html

   APR is already used extensively by the Apache HTTP Server
   version 2 and the Subversion revision control system, to
   name but a few.  We list all known projects using APR at
   http://apr.apache.org/projects.html -- so please let us know
   if you find our libraries useful in your own projects!

Re: [VOTE] Release APR 1.4.8

[Jeff Trawick]

On Mon, Jun 17, 2013 at 10:57 AM, Jeff Trawick  wrote:

> I'll hold the vote open for 72 hours unless something out of the ordinary
> occurs.
>

Thanks everyone for the testing and providing feedback.  as you may have
noticed, I've started rolling out to the mirrors, and I'll announce when
the vast majority look good.

As this is not a security release, I won't wait until Monday to announce.

Peace/love/etc.

Re: [VOTE] Release APR 1.4.8

[Jeff Trawick]

 [+1] Release APR 1.4.8 as GA

No build or test suite issues on FreeBSD 9 "amd64"...

[VOTE] Release APR 1.4.8

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcuts to CHANGES:

http://apr.apache.org/dev/dist/CHANGES-1.4
http://apr.apache.org/dev/dist/CHANGES-1.4.
8

autoconf version: 2.69 (same as apr-util 1.5.2)
libtool version: 2.4.2 (same as apr-util 1.5.2)

+/-1
[  ] Release APR 1.4.8 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

Planning to T&R 1.4.8 in a couple of hours

[Jeff Trawick]

Speak up or not...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.4.7

[Jeff Trawick]

On Sun, May 12, 2013 at 1:11 PM, olli hauer  wrote:

> On 2013-05-12 17:05, olli hauer wrote:
> > On 2013-05-05 00:11, Jeff Trawick wrote:
> >> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
> >>
> >> Shortcuts to CHANGES:
> >>
> >> http://apr.apache.org/dev/dist/CHANGES-1.4
> >> http://apr.apache.org/dev/dist/CHANGES-1.4.7
> >>
> >> autoconf version: 2.69 (same as apr-util 1.5.2)
> >> libtool version: 2.4.2 (same as apr-util 1.5.2)
> >>
> >> +/-1
> >> [  ] Release APR 1.4.7 as GA
> >>
> >> I'll hold the vote open for 72 hours unless something out of the
> ordinary
> >> occurs.
> >>
> >> Thanks in advance for testing!
> >>
> >
> > I have a small patch for FreeBSD on the arm platform.
> > Maybe it's not to late for 1.4.7 ...
> >
> > http://lists.freebsd.org/pipermail/freebsd-apache/2013-May/003137.html
> >
> > --- ./apr-1.4.7/include/apr_general.h.orig
> > +++ ./apr-1.4.7/include/apr_general.h
> > @@ -76,7 +76,7 @@
> >   * @return offset
> >   */
> >
> > -#if defined(CRAY) || (defined(__arm) && !defined(LINUX))
> > +#if defined(CRAY) || (defined(__arm) && !(defined(LINUX) ||
> defined(FreeBSD)))
> >  #ifdef __STDC__
> >  #define APR_OFFSET(p_type,field) _Offsetof(p_type,field)
> >  #else
>
>
> Sorry, the patch was wrong! s/FreeBSD/__FreeBSD__/
>
>
> --- ./apr-1.4.7/include/apr_general.h.orig
> +++ ./apr-1.4.7/include/apr_general.h
> @@ -76,7 +76,7 @@
> ·*·@return·offset
> ·*/
> -#if·defined(CRAY)·||·(defined(__arm)·&&·!defined(LINUX))
>
> +#if·defined(CRAY)·||·(defined(__arm)·&&·!(defined(LINUX)·||·defined(__FreeBSD__)))
> #ifdef·__STDC__
> #define·APR_OFFSET(p_type,field)·_Offsetof(p_type,field)
> #else
>
>
> --
> Regards,
> olli
>

Now committed to trunk/1.5.x/1.4.x...


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr-util v1.6 branch?

[Jeff Trawick]

On Thu, Jun 6, 2013 at 11:00 AM, Graham Leggett  wrote:

> Hi all,
>
> I notice that we don't have an apr-util v1.6 branch at
> https://svn.apache.org/repos/asf/apr/apr-util/branches/.
>
> Obviously there is no trunk branch, as trunk merged with apr, however
> ideally we still need a branch for further development in the v1.x stream.
>
> Should I create an apr-util-1.6.x branch from the head of
> https://svn.apache.org/repos/asf/apr/apr-util/branches/1.5.x/?
>

It makes sense to have it once we have changes that someone wants to
release in 1.x but which can't be released in 1.5.x.  (I guess you already
have such changes in mind so go for it ;) )

As we've had some trouble in the past keeping such next-1.x branches up to
date (mostly minor stuff like doxygen improvements that skipped 1.latest),
I think it is best to defer until actual use.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.4.7

[Jeff Trawick]

I guess we just need the FreeBSD ARM fixes committed and then we can try
for 1.4.8 over the weekend...


On Thu, May 30, 2013 at 8:45 AM, Eric Covener  wrote:

> >>> Does r1487796 (et al) work OK for you guys?
> >>
> >> Mine are failing on IPV6.  I was a bit confused earlier on.
>
> I swore I saw and even logged IPV6 as failing last night, but couldn't
> reproduce a problem there this morning.
>
> On AIX and Solaris/AMD64 pre-r1487796 IPv4 was failing. Works after
> r1487796.
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.4.7

[Jeff Trawick]

On Mon, May 6, 2013 at 6:49 AM, Jeff Trawick  wrote:

> On Sun, May 5, 2013 at 3:40 PM, Eric Covener  wrote:
>
>> confirm test fails on solaris/amd64 too
>>
>
> Unless I've missed something, no one has tested on Windows yet.  I'll try
> to test that in the next few hours to see if there is anything else obvious
> to fix before tagging 1.4.8.
>

1.4.7 built/tested with MinGW shows no regressions from 1.4.6:

 Failed TestsTotal   FailFailed %
===
testdso 5  4 80.00%
testmmap8  3 37.50%
testshm 5  2 40.00%

testshm passes when run as administrator.  IIRC, testdso doesn't work from
MinGW until 1.5, and testmmap has a line ending glitch when you build from
.tar.*z -- some Windows code in the test program expects CRLF in a data
file.

With a Visual Studio 2010 build, testsock is failing inconsistently.  (no
fail, line 234, line 165, now I can't see a failure again ... )  Isn't this
the sort of issue Rainer reported in the past?

It *seems* that Windows has no regressions that are exposed by the APR test
suite, but to be more certain I'd need to bang on testsock a lot harder
with different versions/builds.



>
>>
>> On Sun, May 5, 2013 at 3:12 PM, Eric Covener  wrote:
>> > On Sun, May 5, 2013 at 11:51 AM, Eric Covener 
>> wrote:
>> >> I've got an issue AIX where the test added prior to
>> >>
>> >> http://svn.apache.org/viewvc?view=revision&revision=1309386
>> >>
>> >> Works before r1309386 but not after (EINVAL).  Will look further this
>> evening
>> >
>> > It seems like AIX, Solaris, HP, and Apple are in the byte/char camp
>> >
>> > Linux says integer.
>> >
>> > (This is strictly for the IPv4 flavors)
>> >
>> > Mladen -- do you recall if the 4 byte change for  ipv4 was needed and
>> where?
>>
>>
>>
>> --
>> Eric Covener
>> cove...@gmail.com
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR 1.4.7

[Jeff Trawick]

On Sun, May 5, 2013 at 3:40 PM, Eric Covener  wrote:

> confirm test fails on solaris/amd64 too
>

Unless I've missed something, no one has tested on Windows yet.  I'll try
to test that in the next few hours to see if there is anything else obvious
to fix before tagging 1.4.8.


>
> On Sun, May 5, 2013 at 3:12 PM, Eric Covener  wrote:
> > On Sun, May 5, 2013 at 11:51 AM, Eric Covener  wrote:
> >> I've got an issue AIX where the test added prior to
> >>
> >> http://svn.apache.org/viewvc?view=revision&revision=1309386
> >>
> >> Works before r1309386 but not after (EINVAL).  Will look further this
> evening
> >
> > It seems like AIX, Solaris, HP, and Apple are in the byte/char camp
> >
> > Linux says integer.
> >
> > (This is strictly for the IPv4 flavors)
> >
> > Mladen -- do you recall if the 4 byte change for  ipv4 was needed and
> where?
>
>
>
> --
> Eric Covener
> cove...@gmail.com
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[VOTE] Release APR 1.4.7

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcuts to CHANGES:

http://apr.apache.org/dev/dist/CHANGES-1.4
http://apr.apache.org/dev/dist/CHANGES-1.4.7

autoconf version: 2.69 (same as apr-util 1.5.2)
libtool version: 2.4.2 (same as apr-util 1.5.2)

+/-1
[  ] Release APR 1.4.7 as GA

I'll hold the vote open for 72 hours unless something out of the ordinary
occurs.

Thanks in advance for testing!

Re: 1.4.next next weekend or so?

[Jeff Trawick]

On Fri, May 3, 2013 at 4:08 PM, Stefan Fritsch  wrote:

> On Sunday 28 April 2013, Rainer Jung wrote:
> > On 26.04.2013 21:18, Jeff Trawick wrote:
> > Some warnings during "make check" but probably not new:
> >
> > test/testlockperf.c:229:17: warning: variable 'lockname' set but
> > not used test/testmmap.c:122:18: warning: variable 'rv' set but
> > not used test/testfile.c:739:18: warning: variable 'rv' set but
> > not used test/testfile.c:925:18: warning: variable 'rv' set but
> > not used test/testnames.c:272:9: warning: variable 'hadfailed' set
> > but not used test/echod.c:116:18: warning: variable 'rv' set but
> > not used test/sockperf.c:206:18: warning: variable 'rv' set but
> > not used
>
> Backported
>
> > Looking through all open issues of 2012 and 2013 I find some which
> > might be not to much work:
> >
> > Bug 54892 - Free without malloc (apr_pool_create_unmanaged_ex)
>
> Trunk only, fixed.
>
> >
> > Bug 54779 - apr_sockaddr_info_get() can return APR_SUCCESS when it
> > fails leading to apache 2.4.4 segv
>
> Fixed & backported.
>
> > Bug 54093 - Adding support for 'll' (long long) to snprintf
>
> New feature, should wait for 1.5 IMHO
>
> > Bug 54032 - Default prefix incorrect in configure script
> >
> >
> > Possible trunk backports:
> >
> > Bug 53609 - Apache hangs with terminated signal 6
>
> Was already backported.
>
> >
> > Bug 52785 - testall fails if pool debug is enabled
>
> Needs new API, must wait for 1.5. But API may change again to allow
> mpm-event to work with pool debugging, therefore waiting with backport
> to 1.5.
>
> > Cross compilation stuff:
> >
> > Bug 53425 - Make more cross compiler friendly at configure time
> > Bug 53426 - apr_hints: Fixed underquoted definitions
> > Bug 53427 - apr_network: Fixed underquoted definitions added a
> > default to TRY_RUN for cross-compiling
> > Bug 53428 - apr_threads: Fixed underquoted definitions added a
> > default to TRY_RUN for cross-compiling
> >
> > Other bugs that need more analysis or work on a patch:
> >
> > Bug 53996 - shmget fails on duplicate ftok
> > Bug 53906 - make check failures testsockets testime test_exp_get_lt
> > apr_mcast_hops
> > Bug 54643 - Application exception from Apache 2.4.3 (with APR
> > 1.4.6)
> >
> > Regards,
> >
> > Rainer
>
>

The recent barrage of fixes is awesome.  I'm planning to tag and roll 1.4.7
this afternoon.

1.4.next next weekend or so?

[Jeff Trawick]

I can RM...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Apache Portable Runtime Utility library 1.5.2 Released

[Jeff Trawick]

   The Apache Software Foundation and the Apache Portable Runtime
   Project are proud to announce the General Availability of version
   1.5.2 of the APR Apache Portable Runtime Utility library.

   APR-util 1.5.2 provides a number of bug fixes.

   (See CHANGES-APR-UTIL-1.5 for more information.)

   APR Apache Portable Runtime library version 1.4.6 remains current.

   Version 1.2.1 of the companion APR-iconv library, an alternative
   portable implementation of the 'iconv' library, remains current.

   APR is available for download from:

 http://apr.apache.org/download.cgi

   The mission of the Apache Portable Runtime Project is to create
   and maintain software libraries that provide a predictable and
   consistent interface to underlying platform-specific
   implementations. The primary goal is to provide an API to
   which software developers may code and be assured of predictable
   if not identical behavior regardless of the platform on which
   their software is built, relieving them of the need to code
   special-case conditions to work around or take advantage of
   platform-specific deficiencies or features.

   APR and its companion libraries are implemented entirely in C
   and provide a common programming interface across a wide variety
   of operating system platforms without sacrificing performance.
   Currently supported platforms include:

 UNIX variants
 Windows
 Netware
 Mac OS X
 OS/2

   To give a brief overview, the primary core
   subsystems of APR 1.x include the following:

 Atomic operations
 Dynamic Shared Object loading
 File I/O
 Locks (mutexes, condition variables, etc)
 Memory management (high performance allocators)
 Memory-mapped files
 Multicast Sockets
 Network I/O
 Shared memory
 Thread and Process management
 Various data structures (tables, hashes, priority queues, etc)

   For a more complete list, please refer to the following URLs:

 http://apr.apache.org/docs/apr/modules.html
 http://apr.apache.org/docs/apr-util/modules.html

   Users of APR 0.9 should be aware that migrating to the APR 1.x
   programming interfaces may require some adjustments; APR 1.x is
   neither source nor binary compatible with earlier APR 0.9 releases.
   Users of APR 1.x can expect consistent interfaces and binary backwards
   compatibility throughout the entire APR 1.x release cycle, as defined
   in our versioning rules:

 http://apr.apache.org/versioning.html

   APR is already used extensively by the Apache HTTP Server
   version 2 and the Subversion revision control system, to
   name but a few.  We list all known projects using APR at
   http://apr.apache.org/projects.html -- so please let us know
   if you find our libraries useful in your own projects!

Re: [VOTE] Release APR-util 1.5.2

[Jeff Trawick]

On Tue, Apr 2, 2013 at 2:13 PM, Jeff Trawick  wrote:

> On Sat, Mar 30, 2013 at 4:43 PM, Jeff Trawick  wrote:
>
>> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>>
>> Shortcuts to CHANGES:
>>
>> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.2
>> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>>
>> autoconf version: 2.69 (same as 1.5.1)
>> libtool version: 2.4.2 (1.5.1 had "2.4.2 Debian-2.4.2-1.1"
>>
>> +/-1
>> [  ] Release APR-util 1.5.2 as GA
>>
>>
> The vote passes with these binding votes in favor: covener, minfrin,
> rjung, sf, trawick (and none opposed).  Thanks also to olli haur for his
> input.
>
> I'll start populating the mirrors shortly.
>

A rich sample of mirrors looks good, so I'll update the site and announce
shortly.


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Building the apr runtime library appropriately for the worker MPM

[Jeff Trawick]

On Wednesday, April 3, 2013, Philip Martin wrote:

> Ben Reser > writes:
>
> > On Wed, Apr 3, 2013 at 12:29 PM, Jeff Trawick 
> > >
> wrote:
> >> I'm not aware of any apr_file_lock() use within httpd, so you wouldn't
> >> regress anything (unless you're using third-party modules that use
> >> apr_file_lock).  But I guess you've introduced a third-party module that
> >> uses apr_file_lock() or you wouldn't be asking about this?
> >
> > Subversion uses apr_file_lock() and by extension so does mod_dav_svn.
>
> The main place we use this is in the FSFS backend.  On multi-threaded
> Unix systems we also use a mutex to ensure that only a single thread in
> each process locks the file.  So the use of fcntl() should be OK here as
> far as Subversion is concerned.


Cool, but APR needs a fix...

I didn't get a chance to check where if anywhere APR  uses a pthread mutex
in conjunction with fcntl for mutexes...


> There is also a lock for the BDB backend that is only used for certain
> admin operations and those operations have a restriction that the caller
> is responsible for calling the functions in a single-threaded context.
> These functions are used by the single-threaded svnadmin program.
>
> --
> Philip
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Building the apr runtime library appropriately for the worker MPM

[Jeff Trawick]

On Wed, Apr 3, 2013 at 3:03 PM, Greg Lazar  wrote:

> **
> The apr_file_lock routine, in the version of apr runtime library that I've
> currently built uses fnctl which does not appear to be thread safe. I need
> to use the worker MPM, so is it recommended that I build the apr runtime
> library to use flock instead. NFS file systems aren't a concern in this
> case. I didn't know how extensively the apr_file_lock was used through the
> rest of apache and if I'd be introducing any regressions by switching the
> apr runtime library to use flock.
>

I'm not aware of any apr_file_lock() use within httpd, so you wouldn't
regress anything (unless you're using third-party modules that use
apr_file_lock).  But I guess you've introduced a third-party module that
uses apr_file_lock() or you wouldn't be asking about this?

I guess the apr_file_lock() use of fcntl() needs to get a thread mutex too.

What OS is this?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.2

[Jeff Trawick]

On Sat, Mar 30, 2013 at 4:43 PM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
> Shortcuts to CHANGES:
>
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.2
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>
> autoconf version: 2.69 (same as 1.5.1)
> libtool version: 2.4.2 (1.5.1 had "2.4.2 Debian-2.4.2-1.1"
>
> +/-1
> [  ] Release APR-util 1.5.2 as GA
>
>
The vote passes with these binding votes in favor: covener, minfrin, rjung,
sf, trawick (and none opposed).  Thanks also to olli haur for his input.

I'll start populating the mirrors shortly.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.2

[Jeff Trawick]

On Sat, Mar 30, 2013 at 4:43 PM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
> Shortcuts to CHANGES:
>
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.2
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>
> autoconf version: 2.69 (same as 1.5.1)
> libtool version: 2.4.2 (1.5.1 had "2.4.2 Debian-2.4.2-1.1"
>
> +/-1
>

[+1] Release APR-util 1.5.2 as GA

Tested APR-util 1.5.2 successfully with apr 1.4.6 on

omnios-33fdde4 32-bit, no test failures
Debian wheezy on armv6l (Pi), no test failures

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release APR-util 1.5.2

[Jeff Trawick]

On Sat, Mar 30, 2013 at 4:43 PM, Jeff Trawick  wrote:

> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>
> Shortcuts to CHANGES:
>
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.2
> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>
> autoconf version: 2.69 (same as 1.5.1)
> libtool version: 2.4.2 (1.5.1 had "2.4.2 Debian-2.4.2-1.1"
>
> +/-1
> [  ] Release APR-util 1.5.2 as GA
>
>
I'll close the vote tomorrow.  Thanks for the test reports so far!

Re: [PATCH] Reduce apr_[i|l|off_t_]toa memory footprint for common cases

[Jeff Trawick]

On Mon, Apr 1, 2013 at 6:21 AM, Christophe JAILLET <
christophe.jail...@wanadoo.fr> wrote:

> Le 28/03/2013 19:32, Jeff Trawick a écrit :
>
>  On Thu, Mar 28, 2013 at 1:38 PM, Stefan Fritsch  wrote:
>>
>>> On Monday 25 March 2013, Christophe JAILLET wrote:
>>>
>>>> As a first step, I noticed that apr_itoa, apr_ltoa, apr_off_t_toa
>>>> could  be tweaked to require less memory for some common cases.
>>>> The attached patch reduces memory use for small values, that is to
>>>> say  for strings that fit in 8 bytes (including NULL)
>>>>
>>> Looks like a reasonable optimization to me.
>>>
>>> Cheers,
>>> Stefan
>>>
>> When shrinking it down to 8, why not avoid the apr_palloc altogether?
>> Also, how about lower-casing the name BUFFER_SIZE since it isn't
>> const?
>>
>>
>>  I'm not sure it is possible to avoid the call to apr_palloc.
>

You're correct, of course :)


>
> For BUFFER_SIZE, I 100% agree with you. Previously it was a 'const int',
> and I just left it as it was.
>
> There are also some tab vs space possible clean-up in these functions.
>
> Finally, even if the 3 functions work the same way, they have different
> way to write it:
> *--start = '0' + (n % 10);
> *--start = (char)('0' + (n % 10));
> *--start = '0' + (char)(n % 10);
> The 2nd version is, IMO, the best one.
>

preferred by me too


>
> I didn't include it in my patch to reduce the differences.
>
> CJ
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[VOTE] Release APR-util 1.5.2

[Jeff Trawick]

Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

Shortcuts to CHANGES:

http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5.2
http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5

autoconf version: 2.69 (same as 1.5.1)
libtool version: 2.4.2 (1.5.1 had "2.4.2 Debian-2.4.2-1.1"

+/-1
[  ] Release APR-util 1.5.2 as GA

Re: using new apr-util command-line make files... stuck on apr-iconv

[Jeff Trawick]

Gregg, are the apr-util tests running cleanly for you?  Which level of
Visual Studio are you running?

With 2010+SP1 I get a crash in testbuckets and these two failures.

C:\Users\Trawick\svn\VisualStudio\1.latest\apr-util\test>libd\testall -v -x
test
buckets
teststrmatch: SUCCESS
testuri : SUCCESS
testuuid: SUCCESS
testpass: SUCCESS
testmd4 : SUCCESS
testmd5 : SUCCESS
testcrypto  : SUCCESS
testldap: SUCCESS
testdbd : SUCCESS
testdate: SUCCESS
testmemcache: SUCCESS
testxml : SUCCESS
testxlate   : -Line 63: expected <0>, but saw <22>
FAILED 1 of 1
testrmm : SUCCESS
testdbm : SUCCESS
testqueue   : SUCCESS
testreslist : |Line 255: expected <10>, but saw <20>
FAILED 1 of 1
Failed TestsTotal   FailFailed %
===
testxlate   1  1100.00%
testreslist 1  1100.00%

I don't see them with MinGW builds, but beyond the compiler difference I'm
running that with apr 1.5.x and a different iconv.



On Sat, Mar 30, 2013 at 2:14 PM, Jeff Trawick  wrote:

> On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith  wrote:
>
>> On 3/30/2013 11:01 AM, Jeff Trawick wrote:
>>
>>> To state the obvious, I'm probably doing something stupid.
>>>
>>> I am using Visual Studio 2010 + SP1 (to get around an incremental
>>> linking bug).
>>>
>>> I have a directory with:
>>>
>>> apr-1.4.x as apr
>>> apr-util-1.5.x as apr-util
>>> apr-iconv-1.1.x as apr-iconv
>>>
>>> Within apr-util I try
>>>
>>> l>nmake -f Makefile.win PREFIX=c:\apr1x USEMAK=1 ARCH="Win32 Debug"
>>> buildall checkall
>>>
>>> This fails with
>>>
>>> cd ..\apr-iconv
>>> "c:\Program Files (x86)\Microsoft Visual Studio
>>> 10.0\VC\BIN\nmake.exe" -
>>> nologo -f apriconv.makCFG="apriconv - Win32 Debug" RECURSE=0
>>> NMAKE : fatal error U1052: file 'apriconv.mak' not found
>>> Stop.
>>>
>>> Sure enough, there is no apriconv.mak there.
>>>
>>> Am I supposed to do something first to generate them, before I can use
>>> the apr-util Makefile.win?
>>>
>>
>> Unless you have VC6, use  apr-iconv-1.2.1-win32-src-r2.**zip or steal
>> the .mak/.dep files from it.
>> http://apr.apache.org/**download.cgi <http://apr.apache.org/download.cgi>
>>
>>
> Thanks, I'll use that.
>
> Is there a reason we shouldn't commit the build support to svn?  (Is there
> something unique about that build support that warrants leaving it
> uncommitted?)
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: using new apr-util command-line make files... stuck on apr-iconv

[Jeff Trawick]

On Sat, Mar 30, 2013 at 2:10 PM, Gregg Smith  wrote:

> On 3/30/2013 11:01 AM, Jeff Trawick wrote:
>
>> To state the obvious, I'm probably doing something stupid.
>>
>> I am using Visual Studio 2010 + SP1 (to get around an incremental linking
>> bug).
>>
>> I have a directory with:
>>
>> apr-1.4.x as apr
>> apr-util-1.5.x as apr-util
>> apr-iconv-1.1.x as apr-iconv
>>
>> Within apr-util I try
>>
>> l>nmake -f Makefile.win PREFIX=c:\apr1x USEMAK=1 ARCH="Win32 Debug"
>> buildall checkall
>>
>> This fails with
>>
>> cd ..\apr-iconv
>> "c:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\BIN\nmake.exe" -
>> nologo -f apriconv.makCFG="apriconv - Win32 Debug" RECURSE=0
>> NMAKE : fatal error U1052: file 'apriconv.mak' not found
>> Stop.
>>
>> Sure enough, there is no apriconv.mak there.
>>
>> Am I supposed to do something first to generate them, before I can use
>> the apr-util Makefile.win?
>>
>
> Unless you have VC6, use  apr-iconv-1.2.1-win32-src-r2.**zip or steal the
> .mak/.dep files from it.
> http://apr.apache.org/**download.cgi <http://apr.apache.org/download.cgi>
>
>
Thanks, I'll use that.

Is there a reason we shouldn't commit the build support to svn?  (Is there
something unique about that build support that warrants leaving it
uncommitted?)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

using new apr-util command-line make files... stuck on apr-iconv

[Jeff Trawick]

To state the obvious, I'm probably doing something stupid.

I am using Visual Studio 2010 + SP1 (to get around an incremental linking
bug).

I have a directory with:

apr-1.4.x as apr
apr-util-1.5.x as apr-util
apr-iconv-1.1.x as apr-iconv

Within apr-util I try

l>nmake -f Makefile.win PREFIX=c:\apr1x USEMAK=1 ARCH="Win32 Debug"
buildall checkall

This fails with

cd ..\apr-iconv
"c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\BIN\nmake.exe" -
nologo -f apriconv.makCFG="apriconv - Win32 Debug" RECURSE=0
NMAKE : fatal error U1052: file 'apriconv.mak' not found
Stop.

Sure enough, there is no apriconv.mak there.

Am I supposed to do something first to generate them, before I can use the
apr-util Makefile.win?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

[CONCEPT-PATCH] require --enable-unsupported-freetds to support FreeTDS with apr-util 1.5.x

[Jeff Trawick]

Make sense for post-1.5.2?

This doesn't affect non-autoconf builds, and I think the RPM build would be
broken.  Any other missing pieces?

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/
Index: build/dbd.m4
===
--- build/dbd.m4(revision 1462781)
+++ build/dbd.m4(working copy)
@@ -417,9 +417,22 @@
   old_cppflags="$CPPFLAGS"
   old_ldflags="$LDFLAGS"
 
+  AC_ARG_ENABLE([unsupported-freetds],
+APR_HELP_STRING([--enable-unsupported-freetds],
+  [enable unsupported FreeTDS DBD interface (in combination with 
--with-freetds).
+This driver has known issues and is not currently maintained.  The ODBC driver
+is the recommended solution.]))
+
   AC_ARG_WITH([freetds], 
-APR_HELP_STRING([--with-freetds=DIR], [specify FreeTDS location]),
+APR_HELP_STRING([--with-freetds=DIR], [specify FreeTDS location 
(unsupported)]),
   [
+echo "freetds withval: $withval"
+if test "$withval" != "no"; then
+  if test "$enable_unsupported_freetds" != "yes"; then
+AC_MSG_ERROR(FreeTDS cannot be enabled without 
--enable-unsupported-freetds.)
+  fi
+fi
+
 if test "$withval" = "yes"; then
   AC_CHECK_HEADERS(sybdb.h, AC_CHECK_LIB(sybdb, tdsdbopen, 
[apu_have_freetds=1]))
   if test "$apu_have_freetds" = "0"; then
@@ -444,9 +457,13 @@
   fi
 fi
   ], [
-AC_CHECK_HEADERS(sybdb.h, AC_CHECK_LIB(sybdb, tdsdbopen, 
[apu_have_freetds=1]))
-if test "$apu_have_freetds" = "0"; then
-  AC_CHECK_HEADERS(freetds/sybdb.h, AC_CHECK_LIB(sybdb, tdsdbopen, 
[apu_have_freetds=1]))
+if test "$enable_unsupported_freetds" != "yes"; then
+  AC_MSG_WARN([Skipped FreeTDS detection, --enable-unsupported-freetds not 
specified])
+else
+  AC_CHECK_HEADERS(sybdb.h, AC_CHECK_LIB(sybdb, tdsdbopen, 
[apu_have_freetds=1]))
+  if test "$apu_have_freetds" = "0"; then
+AC_CHECK_HEADERS(freetds/sybdb.h, AC_CHECK_LIB(sybdb, tdsdbopen, 
[apu_have_freetds=1]))
+  fi
 fi
   ])
 

Re: Speak up in the next few hours if you're working on anything for apr-util 1.5.next

[Jeff Trawick]

On Sat, Mar 30, 2013 at 11:18 AM, Nick Kew  wrote:

> On Sat, 30 Mar 2013 10:42:12 -0400
> Jeff Trawick  wrote:
>
> > On Sat, Mar 30, 2013 at 10:38 AM, Nick Kew  wrote:
> >
> > > On Sat, 30 Mar 2013 09:27:40 -0400
> > > Jeff Trawick  wrote:
> > >
> > > On second thoughts, scrub that.
> > >
> > > I'll commit to trunk, but we can't just remove stuff
> > > willy-nilly from 1.5.x.  Sorry for the noise.
> > >
> >
> > Umm, is it an API breakage if it acts as if FreeTDS wasn't found unless
> you
> > build with an extra configure argument?  Yes for some definitions of API,
> > but it may still be appropriate.  At least it doesn't force an
> application
> > change or rebuild.
>
> I guess that could make sense for 1.5.  Can't hack that now 'cos
> I'm just heading off out, but I could try and find time (not today)
> if you think it would be useful.
>
> I was thinking in terms of the more complete removal we've
> discussed here, in the absence of anyone who can maintain it.
>

I'll try to throw together something for 1.5.x and post it soon-ish.


>
>
> --
> Nick Kew
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Speak up in the next few hours if you're working on anything for apr-util 1.5.next

[Jeff Trawick]

On Sat, Mar 30, 2013 at 10:38 AM, Nick Kew  wrote:

> On Sat, 30 Mar 2013 09:27:40 -0400
> Jeff Trawick  wrote:
>
> On second thoughts, scrub that.
>
> I'll commit to trunk, but we can't just remove stuff
> willy-nilly from 1.5.x.  Sorry for the noise.
>

Umm, is it an API breakage if it acts as if FreeTDS wasn't found unless you
build with an extra configure argument?  Yes for some definitions of API,
but it may still be appropriate.  At least it doesn't force an application
change or rebuild.



> --
> Nick Kew
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Speak up in the next few hours if you're working on anything for apr-util 1.5.next

[Jeff Trawick]

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr_memcache operation timeouts

[Jeff Trawick]

(dropping modules-dev)

On Fri, Mar 22, 2013 at 4:04 PM, Joshua Marantz  wrote:
> Thanks very much for doing this, Jeff.
>
> Unfortunately scanning your diff I think you wound up taking a snapshot of
> a patch I'd uploaded to the bug, but not updated after several subsequent
> bug fixes.
>
> The golden copies are in
> https://code.google.com/p/modpagespeed/source/browse/#svn%2Ftrunk%2Fsrc%2Fthird_party%2Faprutil:
>
> https://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/aprutil/apr_memcache2.c
> https://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/aprutil/apr_memcache2.h
>
> After we released our module we had a few small tweaks and bug-fixes based
> on external feedback for our module.  Those versions have now been stable
> for 3.5 months, with multiple users reporting success with our memcached
> integration, so I'm hopeful that they have settled into a stable state.
>
> What's the best way to go from here?

The patch I started with, apparently with fewer changes than what
you're using now, was a bit beyond the number of changes I feel
comfortable with reviewing/testing/committing in one cycle.

Some possibilities:

* somebody in a Rambo mood decides to commit your current stuff
largely as-is to trunk (not me; I don't want to commit anything I
don't understand line by line, and I don't have the time to go through
even more)
* you or somebody else split your code into a series of easy to
understand patches that solve one problem and which can be backported
back to 1.5.x without breaking anything
* ???

Before anyone commits, some of the tweaks in my patch need to be
carried forward, including zapping asserts and the related change to
the public structure.  (ISTR adding an error check for a pollset
operation that we have seen fail in httpd-land.)

>
> -Josh
>
>
> On Thu, Mar 14, 2013 at 10:45 AM, Jeff Trawick  wrote:
>
>> On Tue, Mar 12, 2013 at 1:56 PM, Jeff Trawick  wrote:
>> > On Mon, Mar 11, 2013 at 3:50 PM, Joshua Marantz 
>> wrote:
>> >>
>> >> ping!
>> >>
>> >> Please don't hesitate to push back and tell me if I can supply the patch
>> >> or
>> >> update in some easier-to-digest form.  In particular, while I have
>> >> rigorously stress-tested this change using mod_pagespeed's unit test,
>> >> system-test, and load-test framework, I don't really understand what the
>> >> testing flow is for APR.  I'd be happy to add unit-tests for that if
>> >> someone points me to a change-list or patch-file that does it properly.
>> >>
>> >> -Josh
>> >
>> >
>> > I'll try hard to work on this in the next couple of days.  It would be
>> great
>> > to have fixes in APR-Util 1.5.x, which we hope to work on later this
>> week.
>>
>> Attached is a first pass at getting your patch to apr trunk.  Can you
>> confirm that I didn't break your tests?  (It passes the apr tests, but
>> that may not mean much.)
>>
>>
>>
>> >
>> >>
>> >>
>> >> On Thu, Nov 1, 2012 at 8:04 AM, Joshua Marantz 
>> >> wrote:
>> >>
>> >> > I have completed a solution to this problem, which can be a drop-in
>> >> > update
>> >> > for the existing apr_memcache.c.  It is now checked in for my module
>> as
>> >> >
>> >> >
>> http://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/aprutil/apr_memcache2.c
>> >> > .
>> >> >
>> >> > It differs from the solution in
>> >> > https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 in that:
>> >> >
>> >> >- It doesn't require an API change; it but it enforces the 50ms
>> >> >timeout that already exists for apr_multgetp for all operations.
>> >> >- It works under my load test (which I found is not true of the
>> patch
>> >> >in 51065).
>> >> >
>> >> > For my own purposes, I will be shipping my module with apr_memcache2
>> so
>> >> > I
>> >> > get the behavior I want regardless of what version of Apache is
>> >> > installed.
>> >> >  But I'd like to propose my patch for apr_memcache.c.  The patch is
>> >> > attached, and I've also submitted it as an alternative patch to bug
>> >> > 51065.
>> >> >
>> >> > If you agree with the strategy I used to solve this problem, then
>> please
>

Re: time for APU 1.5.2?

[Jeff Trawick]

On Fri, Mar 29, 2013 at 6:54 AM, Stefan Fritsch  wrote:
> On Monday 11 March 2013, Jeff Trawick wrote:
>> That sounds like a good idea.
>>
>> I can RM in a few days.
>
> Is there anything important missing? AFAICS, the memcached changes
> proposed by Joshua Marantz add a new field to a public struct and
> therefore need to wait for 1.6.

My version of the patch does not.  But that's a separate conversation.

> I could T&R tomorrow or on Monday.

Go for it ;)  I didn't want to T&R until activity had died down.
Since you're the activity, you know when that has happened.  (If you
get busy I'll take care of it.)

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [PATCH] Reduce apr_[i|l|off_t_]toa memory footprint for common cases

[Jeff Trawick]

On Thu, Mar 28, 2013 at 1:38 PM, Stefan Fritsch  wrote:
> On Monday 25 March 2013, Christophe JAILLET wrote:
>> As a first step, I noticed that apr_itoa, apr_ltoa, apr_off_t_toa
>> could  be tweaked to require less memory for some common cases.
>> The attached patch reduces memory use for small values, that is to
>> say  for strings that fit in 8 bytes (including NULL)
>
> Looks like a reasonable optimization to me.
>
> Cheers,
> Stefan

When shrinking it down to 8, why not avoid the apr_palloc altogether?
Also, how about lower-casing the name BUFFER_SIZE since it isn't
const?


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Does APR_HAVE_LIMITS_H do anything on Dev Studio builds?

[Jeff Trawick]

On Wed, Mar 27, 2013 at 1:12 AM, Joe Swatosh  wrote:
> Hi All,
>
> I've downloaded a few versions of APR and looked into apr.hw on each
> of them and I see APR_HAVE_LIMITS_H being set, but I don't see the
> equivalent of block like:
>
> /* header files for PATH_MAX, _POSIX_PATH_MAX */
> #if APR_HAVE_LIMITS_H
> #include 
> #else
> #if APR_HAVE_SYS_SYSLIMITS_H
> #include 
> #endif
> #endif
>
> which I find in apr.h.in.
>
> I must be missing something. How is this supposed to work?

I think what this means is that apr.h on Unix needed something from
that file (presumably *_PATH_MAX) in order to work, but it wasn't
needed on Windows.

So you're left with a side effect (including that .h file) on Unix
that doesn't exist on Windows.  Either way you have APR_HAVE_foo_H
exported in case you need to use it.

Was your APR app missing something from limits.h when compiled on
Windows, or did you encounter some other sort of problem because of
this?

>
> Thanks!
> --
> Joe



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: bug 54572 -- move struct crypt_data allocation to heap

[Jeff Trawick]

On Sat, Mar 23, 2013 at 6:22 PM, Stefan Fritsch  wrote:
> On Saturday 23 March 2013, Jeff Trawick wrote:
>> On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch 
> wrote:
>> > On Saturday 16 March 2013, Jeff Trawick wrote:
>> >> This would be good to resolve in 1.5.2.
>> >>
>> >> Has anyone else evaluated this?  I'm suspicious of the use of a
>> >> global pool in the reporter's patch vs. just using malloc()
>> >> directly.  I guess the reason for using the pool is that the
>> >> allocator may have suitable buffers lying around, but you need
>> >> one for the pool and one for the structure instead of just
>> >> getting one from malloc().  I haven't tried any performance
>> >> tests yet.
>> >
>> > An alternative would be using apr_allocator_alloc() directly
>> > (with the global pool's allocator). Creating a sub-pool seems
>> > more overhead than necessary. Not sure what is better, malloc()
>> > or apr_allocator_alloc().
>>
>> No good way to get to global_pool/global_allocator from outside
>> apr_pools.c AFAICT
>>
>> I think malloc() wins here...
>
> You are right. What about
>
> http://svn.apache.org/r1460243

Looks good here...

>
> Anyone has a system using CRYPTD to test this?

Not me (chuckle)...

AIX anyone?

Re: bug 54572 -- move struct crypt_data allocation to heap

[Jeff Trawick]

On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch  wrote:
> On Saturday 16 March 2013, Jeff Trawick wrote:
>> This would be good to resolve in 1.5.2.
>>
>> Has anyone else evaluated this?  I'm suspicious of the use of a
>> global pool in the reporter's patch vs. just using malloc()
>> directly.  I guess the reason for using the pool is that the
>> allocator may have suitable buffers lying around, but you need one
>> for the pool and one for the structure instead of just getting one
>> from malloc().  I haven't tried any performance tests yet.
>
> An alternative would be using apr_allocator_alloc() directly (with the
> global pool's allocator). Creating a sub-pool seems more overhead than
> necessary. Not sure what is better, malloc() or apr_allocator_alloc().

No good way to get to global_pool/global_allocator from outside
apr_pools.c AFAICT

I think malloc() wins here...

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

bug 54572 -- move struct crypt_data allocation to heap

[Jeff Trawick]

This would be good to resolve in 1.5.2.

Has anyone else evaluated this?  I'm suspicious of the use of a global
pool in the reporter's patch vs. just using malloc() directly.  I
guess the reason for using the pool is that the allocator may have
suitable buffers lying around, but you need one for the pool and one
for the structure instead of just getting one from malloc().  I
haven't tried any performance tests yet.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr_memcache operation timeouts

[Jeff Trawick]

On Tue, Mar 12, 2013 at 1:56 PM, Jeff Trawick  wrote:
> On Mon, Mar 11, 2013 at 3:50 PM, Joshua Marantz  wrote:
>>
>> ping!
>>
>> Please don't hesitate to push back and tell me if I can supply the patch
>> or
>> update in some easier-to-digest form.  In particular, while I have
>> rigorously stress-tested this change using mod_pagespeed's unit test,
>> system-test, and load-test framework, I don't really understand what the
>> testing flow is for APR.  I'd be happy to add unit-tests for that if
>> someone points me to a change-list or patch-file that does it properly.
>>
>> -Josh
>
>
> I'll try hard to work on this in the next couple of days.  It would be great
> to have fixes in APR-Util 1.5.x, which we hope to work on later this week.

Attached is a first pass at getting your patch to apr trunk.  Can you
confirm that I didn't break your tests?  (It passes the apr tests, but
that may not mean much.)



>
>>
>>
>> On Thu, Nov 1, 2012 at 8:04 AM, Joshua Marantz 
>> wrote:
>>
>> > I have completed a solution to this problem, which can be a drop-in
>> > update
>> > for the existing apr_memcache.c.  It is now checked in for my module as
>> >
>> > http://code.google.com/p/modpagespeed/source/browse/trunk/src/third_party/aprutil/apr_memcache2.c
>> > .
>> >
>> > It differs from the solution in
>> > https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 in that:
>> >
>> >- It doesn't require an API change; it but it enforces the 50ms
>> >timeout that already exists for apr_multgetp for all operations.
>> >- It works under my load test (which I found is not true of the patch
>> >in 51065).
>> >
>> > For my own purposes, I will be shipping my module with apr_memcache2 so
>> > I
>> > get the behavior I want regardless of what version of Apache is
>> > installed.
>> >  But I'd like to propose my patch for apr_memcache.c.  The patch is
>> > attached, and I've also submitted it as an alternative patch to bug
>> > 51065.
>> >
>> > If you agree with the strategy I used to solve this problem, then please
>> > let me know if I can help with any changes required to get this into the
>> > main distribution,
>> >
>> >
>> > On Mon, Oct 22, 2012 at 5:21 PM, Joshua Marantz
>> > wrote:
>> >
>> >> I've had some preliminary success with my own variant of apr_memcache.c
>> >> (creatively called apr_memcache2.c).  Rather than setting the socket
>> >> timeout, I've been mimicing the timeout strategy I saw in
>> >> apr_memcache_multgetp, by adding a new helper method:
>> >>
>> >> static apr_status_t wait_for_server_or_timeout(apr_pool_t* temp_pool,
>> >>apr_memcache2_conn_t*
>> >> conn) {
>> >> apr_pollset_t* pollset;
>> >> apr_status_t rv = apr_pollset_create(&pollset, 1, temp_pool, 0);
>> >> if (rv == APR_SUCCESS) {
>> >> apr_pollfd_t pollfd;
>> >> pollfd.desc_type = APR_POLL_SOCKET;
>> >> pollfd.reqevents = APR_POLLIN;
>> >> pollfd.p = temp_pool;
>> >> pollfd.desc.s = conn->sock;
>> >> pollfd.client_data = NULL;
>> >> apr_pollset_add(pollset, &pollfd);
>> >> apr_int32_t queries_recvd;
>> >> const apr_pollfd_t* activefds;
>> >> rv = apr_pollset_poll(pollset, MULT_GET_TIMEOUT,
>> >> &queries_recvd,
>> >>   &activefds);
>> >> if (rv == APR_SUCCESS) {
>> >> assert(queries_recvd == 1);
>> >> assert(activefds->desc.s == conn->sock);
>> >> assert(activefds->client_data == NULL);
>> >> }
>> >> }
>> >> return rv;
>> >> }
>> >>
>> >> And calling that before many of the existing calls to get_server_line
>> >> as:
>> >>
>> >> rv = wait_for_server_or_timeout_no_pool(conn);
>> >> if (rv != APR_SUCCESS) {
>> >> ms_release_conn(ms, conn);
>> >> return rv;
>> >> }
>> >>
>> >> This is just an experiment; I think I can streamline this by
>> >> pre-populating the pollfd structure as part of the 

Re: apr_memcache operation timeouts

[Jeff Trawick]

xtra
> >> call to poll, rather than relying on the socket timeout.  The socket
> >> timeout didn't work as well as this though.  Does anyone have any
> theories
> >> as to why, or what could be done to the patch in
> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51065 to work?
> >>
> >> -Josh
> >>
> >>
> >> On Fri, Oct 19, 2012 at 9:25 AM, Joshua Marantz  >wrote:
> >>
> >>> Following up: I tried doing what I suggested above: patching that
> change
> >>> into my own copy of apr_memcache.c  It was first of all a bad idea to
> pull
> >>> in only part of apr_memcache.c because that file changed slightly
> between
> >>> 2.2 and 2.4 and our module works in both.
> >>>
> >>> I was successful making my own version of apr_memcache (renaming
> >>> entry-points apr_memcache2*) that I could hack.  But if I changed the
> >>> socket timeout from -1 to 10 seconds, then the system behaved very
> poorly
> >>> under load test (though it worked fine in our unit-tests and
> system-tests).
> >>>  In other words, I think the proposed patch that Jeff pointed to above
> is
> >>> not really working (as he predicted).  This test was done without
> >>> SIGSTOPing the memcached; it would timeout under our load anyway and
> >>> thereafter behave poorly.
> >>>
> >>> I'm going to follow up on that bugzilla entry, but for now I'm going to
> >>> pursue my own complicated mechanism of timing out the calls from my
> side.
> >>>
> >>> -Josh
> >>>
> >>>
> >>> On Thu, Oct 18, 2012 at 10:46 AM, Joshua Marantz  >wrote:
> >>>
> >>>> Thanks Jeff, that is very helpful.  We are considering a course of
> >>>> action and before doing any work toward this, I'd like to understand
> the
> >>>> pitfalls from people that understand Apache better than us.
> >>>>
> >>>> Here's our reality: we believe we need to incorporate memcached for
> >>>> mod_pagespeed <http://modpagespeed.com> to scale effectively for very
> >>>> large sites & hosting providers.  We are fairly close (we think) to
> >>>> releasing this functionality as beta.  However, in such large sites,
> stuff
> >>>> goes wrong: machines crash, power failure, fiber cut, etc.  When it
> does we
> >>>> want to fall back to serving partially unoptimized sites rather than
> >>>> hanging the servers.
> >>>>
> >>>> I understand the realities of backward-compatible APIs.  My
> expectation
> >>>> is that this would take years to make it into an APR distribution we
> could
> >>>> depend on.  We want to deploy this functionality in weeks.  The
> workarounds
> >>>> we have tried backgrounding the apr_memcache calls in a thread and
> timing
> >>>> out in mainline are complex and even once they work 100% will be very
> >>>> unsatisfactory (resource leaks; Apache refusing to exit cleanly on
> >>>> 'apachectl stop') if this happens more than (say) once a month.
> >>>>
> >>>> Our plan is to copy the patched implementation of
> >>>> apr_memcache_server_connect and the static methods it calls into a
> new .c
> >>>> file we will link into our module, naming the new entry-point
> something
> >>>> else (apr_memcache_server_connect_with_timeout seems good).  From a
> >>>> CS/SE perspective this is offensive and we admit it, but from a
> product
> >>>> quality perspective we believe this beats freezes and
> complicated/imperfect
> >>>> workarounds with threads.
> >>>>
> >>>> So I have two questions for the Apache community:
> >>>>
> >>>>1. What are the practical problems with this approach?  Note that
> >>>>in any case a new APR rev would require editing/ifdefing our code
> anyway,
> >>>>so I think immunity from APR updates such as this patch being
> applied is
> >>>>not a distinguishing drawback.
> >>>>2. Is there an example of the correct solution to the technical
> >>>>problem Jeff highlighted: "it is apparently missing a call to
> >>>>adjust the socket timeout and to discard the connection if the
> >>>>timeout is reached".  That sounds like a pattern that might 

Re: time for APU 1.5.2?

[Jeff Trawick]

On Mon, Mar 11, 2013 at 10:32 AM, Guenter Knauf  wrote:

> Hi all,
> since the APU 1.5.1 apr_password_validate() bug is now fixed (thanks
> Rainer!), and our main site http://apr.apache.org/ still lists:
>
> The recommended releases of the several Apache Portable Runtime libraries
> are
>
> * APR 1.4.6, released Feb 14, 2012
> * APR-util 1.5.1, released October 5, 2012
> * APR-iconv 1.2.1, released November 26, 2007
>
> I believe we shoud soon put another release APU 1.5.2 out ...
> would be great if we would couple it also with another APU 1.4.7 release
> ...
> anybody with the right resources (Linux autofoo) willing to RM?
>

That sounds like a good idea.

I can RM in a few days.



>
> Gün.
>
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Migrating APR-site to the ASF CMS

[Jeff Trawick]

On Mon, Dec 10, 2012 at 2:36 AM, Igor Galić  wrote:

>
> Hello Happy People o/~
>
> Seeing Infra's latest email and having done a couple of CMS
> migrations in the last year, I would like to offer my
> assistance in this endeavour to whomever it may concern.
>
> So long,
>

Please/Thank You :)

Do you know the current state of conversion tools?  IIRC the httpd pages
needed a lot of manual help after the initial pass.



>
> i
>
> --
> Igor Galić
>
> Tel: +43 (0) 664 886 22 883
> Mail: i.ga...@brainsware.org
> URL: http://brainsware.org/
> GPG: 6880 4155 74BD FD7C B515  2EA5 4B1D 9E08 A097 C9AE
>
>


-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Redirect the request in fixup phase

[Jeff Trawick]

On Thursday, November 29, 2012, amitvce wrote:

>
> Hi Everybody,
>
> Can anybody help me here


d...@httpd.apache.org is the list to use for this query


>
> I implemented request fix up phase to manipulate some cookie coming along
> with request. I want , in some conditions .. request instead of traveling
> to
> application server , redirect the user to a defined url.
>
> So i want the mechanism which can help me redirecting the user in request
> fix up phase ( on some condition) instead of letting the request go
> application server ( websphere).. How can i achieve that.
>
> Thanks
> --
> View this message in context:
> http://old.nabble.com/Redirect-the-request-in-fixup-phase-tp34739255p34739255.html
> Sent from the APR Dev (Apache Portable Runtime) mailing list archive at
> Nabble.com.
>
>

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: buildbot failure in ASF Buildbot on apr-trunk-fbsd

[Jeff Trawick]

On Sat, Nov 3, 2012 at 3:14 PM,   wrote:
> The Buildbot has detected a new failure on builder apr-trunk-fbsd while 
> building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/apr-trunk-fbsd/builds/123
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: bb-fbsd2_64bit
>
> Build Reason: scheduler
> Build Source Stamp: [branch apr/apr/trunk] 1405402
> Blamelist: trawick
>
> BUILD FAILED: failed compile_3

testshm :  Line 154: expected <100>, but saw <96>
FAILED 1 of 6

(shrug)

>
> sincerely,
>  -The Buildbot
>
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr_memcache operation timeouts

[Jeff Trawick]

On Wed, Oct 17, 2012 at 3:36 PM, Joshua Marantz  wrote:
> Is there a mechanism to time out individual operations?

No, the socket connect timeout is hard-coded at 1 second and the
socket I/O timeout is disabled.

Bugzilla bug https://issues.apache.org/bugzilla/show_bug.cgi?id=51065
has a patch, though it is apparently missing a call to adjust the
socket timeout and to discard the connection if the timeout is
reached.  More importantly, the API can only be changed in future APR
2.0; alternate, backwards-compatible API(s) could be added in future
APR-Util 1.6.

>
> If memcached freezes, then it appears my calls to 'get' will block until
> memcached wakes up.  Is there any way to set a timeout for that call?
>
> I can repro this in my unit tests by sending a SIGSTOP to memcached before
> doing a 'get'?
>
> Here are my observations:
>
> apr_memcache_multgetp seems to time out in bounded time if I SIGSTOP the
> memcached process. Yes!
>
> apr_memcache_getp seems to hang indefinitely if I SIGSTOP the memcached
> process.
>
> apr_memcache_set seems to hang indefinitely if I SIGSTOP the memcached
> process.
>
> apr_memcache_delete seems to hang indefinitely if I SIGSTOP the memcached
> process.
>
> apr_memcache_stats seems to hang indefinitely if I SIGSTOP the memcached
> process.
>
> That last one really sucks as I am using that to print the status of all my
> cache shards to the log file if I detected a problem :(
>
>
> Why does apr_memcache_multgetp do what I want and not the others?  Can I
> induce the others to have reasonable timeout behavior?
>
> When I SIGSTOP memcached this makes it hard to even restart Apache, at
> least with graceful-stop.
>
>
> On a related note, the apr_memcache
> documentationis
> very thin.  I'd be happy to augment it with my observations on its
> usage
> and the meaning of some of the arguments if that was desired.  How would I
> go about that?

Check out APR trunk from Subversion, adjust the doxygen docs in the
include files, build (make dox) and inspect the results, submit a
patch to dev@apr.apache.org.

>
> -Josh



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: aprmemcache question

[Jeff Trawick]

On Thu, Sep 27, 2012 at 1:55 PM, Joshua Marantz  wrote:
> That one call-site is HTTP_24/src/modules/cache/mod_socache_memcache.c,
> right?  That was where I stole my args from.

no, subversion

> As the TCP/IP layer is a lower level abstraction than bathe apr_memcache
> interface, I'm still not clear on exactly what that means.  Does a value of
> 600 mean that a single multiget must complete in 600 microseconds otherwise
> it fails with APR_TIMEUP?

ttl only affects connections which are not currently used; it does not
control I/O timeouts


> That might explain the behavior I saw.
>
> I've now jacked that up by x1e6  to 600 seconds and I don't see timeouts,
> but I'm hoping someone can bridge the gap between the socket-level
> explanation and the apr_memcache API call.
>
> I was assuming that apr_memcache created the TCP/IP connection when I called
> apr_memcache_server_create, and there even 600 seconds seems too short.  Is
> the functionality more like it will create connections on-demand and leave
> them running for N microseconds, re-using the connection for multiple
> requests until TTL microseconds have elapsed since creation?

create on demand
reuse existing idle connections when possible
when performing maintenance on the idle connections, clean up any
which were idle for N microseconds

If a connection is always reused before it is idle for N microseconds,
it will live as long as memcached allows.

> If that's the case then I guess that every 10 minutes one of my cache
> lookups may have high latency to re-establish the connection, is that right?
> I've been histogramming this under load and seeing some long tail requests
> with very high latency.  My median latency is only 143us which is great.
> My 90%, 95% and 99% are all around 5ms, which is fine as well.  But I've got
> a fairly significant number of long-tail lookups that take hundreds of ms or
> even seconds to finish, and one crazy theory is that this is all reconnect
> cost.
>
> It would be nice if the TTL were interpreted as a maximum idle time before
> the connection is reaped, rather than stuttering response-time on a very
> active channel.

It is.  The ttl is interpreted by the reslist layer, which won't touch
objects until they're returned to the list.

>
> This testing is all using a single memcached running on localhost.
>
> -Josh
>
>
> On Thu, Sep 27, 2012 at 11:24 AM, Jeff Trawick  wrote:
>>
>> On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz 
>> wrote:
>> > On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis 
>> > wrote:
>> >>
>> >>   If dlsym() is called with the special handle NULL, it is interpreted
>> >> as
>> >> a
>> >>   reference to the executable or shared object from which the call is
>> >> being
>> >>   made.  Thus a shared object can reference its own symbols.
>> >>
>> >> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD
>> >> as
>> >> well.
>> >
>> >
>> > Cool, thanks.
>> >>
>> >> > Do you have a feel for the exact meaning of that TTL parameter to
>> >> > apr_memcache_server_create?
>> >>
>> >> You mean what units it uses? Microseconds (at least, in 2.4).
>> >
>> >
>> > Actually what I meant was what that value is used for in the library.
>> > The
>> > phrase "time to live of client connection" confuses me.  Does it really
>> > mean
>> > "the maximum number of seconds apr_memcache is willing to wait for a
>> > single
>> > operation?  Or does it mean *both*, implying that a fresh TCP/IP
>> > connection
>> > is made for every new operation, but will stay alive for only a certain
>> > number of seconds.
>>
>> TCP/IP connections, once created, will be retained for the specified
>> (ttl) number of seconds.  They'll be created when needed.
>>
>> The socket connect timeout is hard-coded to 1 second, and there's no
>> timeout for I/O.
>>
>> >
>> >
>> > It is a little disturbing from a module-developer perspective to have
>> > the
>> > meaning of that parameter change by a factor of 1M between versions.
>> > Would
>> > it be better to revert the recent change and instead change the doc to
>> > match
>> > the current behavior?
>>
>> The doc was already changed to match the behavior, but I missed that.
>> The caller I know of used the wrong unit, and I'll submit a patch to
>> fix that in the caller, as well as revert my screw-up from yesterday.
>>
>> >
>> > -Josh
>> >
>>
>>
>>
>> --
>> Born in Roswell... married an alien...
>> http://emptyhammock.com/
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: aprmemcache question

[Jeff Trawick]

On Thu, Sep 27, 2012 at 11:15 AM, Joshua Marantz  wrote:
> On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis  wrote:
>>
>>   If dlsym() is called with the special handle NULL, it is interpreted as
>> a
>>   reference to the executable or shared object from which the call is
>> being
>>   made.  Thus a shared object can reference its own symbols.
>>
>> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as
>> well.
>
>
> Cool, thanks.
>>
>> > Do you have a feel for the exact meaning of that TTL parameter to
>> > apr_memcache_server_create?
>>
>> You mean what units it uses? Microseconds (at least, in 2.4).
>
>
> Actually what I meant was what that value is used for in the library.  The
> phrase "time to live of client connection" confuses me.  Does it really mean
> "the maximum number of seconds apr_memcache is willing to wait for a single
> operation?  Or does it mean *both*, implying that a fresh TCP/IP connection
> is made for every new operation, but will stay alive for only a certain
> number of seconds.

TCP/IP connections, once created, will be retained for the specified
(ttl) number of seconds.  They'll be created when needed.

The socket connect timeout is hard-coded to 1 second, and there's no
timeout for I/O.

>
>
> It is a little disturbing from a module-developer perspective to have the
> meaning of that parameter change by a factor of 1M between versions.  Would
> it be better to revert the recent change and instead change the doc to match
> the current behavior?

The doc was already changed to match the behavior, but I missed that.
The caller I know of used the wrong unit, and I'll submit a patch to
fix that in the caller, as well as revert my screw-up from yesterday.

>
> -Josh
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: aprmemcache question

[Jeff Trawick]

On Thu, Sep 27, 2012 at 10:58 AM, Ben Noordhuis  wrote:
> On Thu, Sep 27, 2012 at 4:29 PM, Joshua Marantz  wrote:
>> Thanks Ben,
>>
>> That might be an interesting hack to try, although I wonder whether some of
>> our friends running mod_pagespeed on FreeBSD might run into trouble with
>> it.  I did confirm that my prefork build has APR built with
>> APR_HAS_THREADS, which for some reason I had earlier thought was not the
>> case.
>
> It should work, provided you linked against libapr. The FreeBSD man
> page says this:
>
>   If dlsym() is called with the special handle NULL, it is interpreted as a
>   reference to the executable or shared object from which the call is being
>   made.  Thus a shared object can reference its own symbols.
>
> And that's how it works on Linux, Solaris, NetBSD and probably OpenBSD as 
> well.
>
>> Do you have a feel for the exact meaning of that TTL parameter to
>> apr_memcache_server_create?
>
> You mean what units it uses? Microseconds (at least, in 2.4).

Right.  I screwed up on changing that yesterday.  The APR doc was
already fixed long ago to indicate it was microseconds instead of
seconds, the Subversion code hasn't been fixed to respect that, and
the bug that was opened to fix the code to use seconds put me in the
wrong frame of mind :(

What does ttl mean for this particular API?

All resources in the resource list are cleaned up when the memcache
server is deleted/pool is cleared/destroyed.

Individual resources are returned to the list at the end of individual
memcache operations.  When a resource is returned to the list, "old"
resources are destroyed, where "old" is determined by the ttl.
Destroying a memcache resource means it sends the "quit" message to
memcached and closes the socket.  So ttl sets a limit on how long a
particular connection to memcached can be used.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: aprmemcache question

[Jeff Trawick]

On Wed, Sep 26, 2012 at 7:31 PM, Joshua Marantz  wrote:
> Looking at source, I see that Jeff's patch, and the 'ttl' parameter in
> general, is only referenced under '#if APR_HAS_THREADS'.  When I
> load-tested and found the timeouts, I was testing under Apache 2.2 Prefork,
> and thus that patched code is not even compiled, IIUC.
>
> However I would still like to know what that parameter is for when running
> under Worker.
>
> I think the implication of my source journey is also that if my module
> instantiates multiple threads under Prefork (which it does), it must call
> apr_memcache* routines from only one of them.  Is that correct?

APR is usually compiled with thread support even when using the
prefork MPM.  Check APR_HAS_THREADS in apr.h.

If APR_HAS_THREADS is 0 (very unlikely), you probably want to fail the
build of your module to avoid having to worry about this.

As far as what the parameter means...  I'll try to look tomorrow if
nobody replies first.

See apu_version() for the APR-util version.

>
> -Josh
>
>
> On Wed, Sep 26, 2012 at 7:17 PM, Joshua Marantz  wrote:
>
>> +dev (sorry for the duplicate; my first attempt failed due to not being a
>> subscriber).
>>
>> Keeping modules-dev on CC if that's appropriate.
>>
>> Thanks, Jeff, I was wondering if there was a units issue there.  I'm still
>> wondering if anyone can describe the meaning of that argument in more
>> detail.  Is that related to my multiget APR_TIMEUP returns?   The phrase
>> "time to live of client connection" confuses me.  Would it be inaccurate to
>> instead say "the maximum number of seconds apr_memcache is willing to wait
>> for a single operation?  Or does it mean *both*, implying that a fresh
>> TCP/IP connection is made for every new operation, but will stay alive for
>> only a certain number of seconds.
>>
>> I have a practical question about how I release software given this
>> change.  Our module (mod_pagespeed) is documented to run with Apache 2.2
>> and Apache 2.4.  It seems like for 2.2 I should probably multiple my
>> desired argument by a million.  Same with for 2.4.x and earlier, for some
>> value of x.  How should I work this in my code?  Should I query the version
>> number using an apr utility or something and multiply by a million in
>> certain cases?
>>
>> What's the best practice calling this function for module developers?
>>
>> -Josh
>>
>>
>> On Wed, Sep 26, 2012 at 6:20 PM, Jeff Trawick  wrote:
>>
>>> On Wed, Sep 26, 2012 at 5:38 PM, Joshua Marantz 
>>> wrote:
>>> > Hi,
>>> >
>>> > I've been having some success with the apr_memcache_* functions.  In
>>> > load-tests, however, I'm finding a lot of timeouts
>>> > with apr_memcache_multgetp.  Specifically, the status returned with the
>>> > individual elements is APR_TIMEUP.
>>> >
>>> > This leads me to wonder what the significance of the second to last arg
>>> to
>>> > this function is:
>>> >
>>> > apr_memcache_server_create(
>>> >   pool_, hosts_[i].c_str(), ports_[i],
>>> >   kDefaultServerMin, kDefaultServerSmax,
>>> >   thread_limit_, kDefaultServerTtlUs, &server);
>>> >
>>> > I have kDefaultServerSmax initialized to 600, as that's the value I
>>> found
>>> > in mod_socache_memcache.c   But that seems stingy (if it's really in
>>> > microseconds).  Should I be giving that a few hundred millis instead?
>>> >
>>> http://apr.apache.org/docs/apr-util/1.4/group___a_p_r___util___m_c.html#ga18ddd72bc1ab5edb0a08a8f26f193bd3
>>> > claims
>>> > that means "time to live of client connection" but I don't understand
>>> what
>>> > that phrase means exactly, or if it relates to the APR_TIMEUP returns
>>> I've
>>> > been suffering from.
>>> >
>>> > My code is here;
>>> >
>>> http://code.google.com/p/modpagespeed/source/browse/trunk/src/net/instaweb/apache/apr_mem_cache.cc
>>> >
>>> > -Josh
>>>
>>> dev@apr.apache.org is a better place to ask about details of apr
>>> functions.
>>>
>>> Coincidentally, earlier today I committed someone's fix for the
>>> confusion about the units of ttl:
>>>
>>> http://svn.apache.org/viewvc?view=revision&revision=1390530
>>>
>>> It is supposed to be in seconds.  Pick up the tiny change to
>>> apr_memcache.c and see if that helps anything.  You should continue
>>> this discussion on dev@apr.apache.org.
>>>
>>> --
>>> Born in Roswell... married an alien...
>>> http://emptyhammock.com/
>>>
>>
>>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr_memcache tries a dead server for each request, not every 5 secs as per comment

[Jeff Trawick]

On Tue, Sep 25, 2012 at 2:34 PM, Jeff Trawick  wrote:
> On Tue, Sep 25, 2012 at 11:54 AM, Gavin Shelley  wrote:
>>
>> The comment says:
>>
>> /* Try the dead server, every 5 seconds */
>>
>> but the code looks to try for each request more than 5 seconds after the 
>> dead server was first noticed.
>>
>> If I'm correct, does the following (untested) patch make sense?
>>
>>
>>
>>
>> Index: memcache/apr_memcache.c
>> ===
>> --- memcache/apr_memcache.c (revision 1389910)
>> +++ memcache/apr_memcache.c (working copy)
>> @@ -183,8 +183,8 @@
>>  #endif
>>  /* Try the dead server, every 5 seconds */
>>  if (curtime - ms->btime >  apr_time_from_sec(5)) {
>> +ms->btime = curtime;
>>  if (mc_version_ping(ms) == APR_SUCCESS) {
>> -ms->btime = curtime;
>>  make_server_live(mc, ms);
>>  #if APR_HAS_THREADS
>>  apr_thread_mutex_unlock(ms->lock);n
>>
>
> It looks correct to me.

I've committed your fix to apr trunk and apr-util 1.5.x and 1.4.x
branches. Thanks!

>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: apr_memcache tries a dead server for each request, not every 5 secs as per comment

[Jeff Trawick]

On Tue, Sep 25, 2012 at 11:54 AM, Gavin Shelley  wrote:
>
> The comment says:
>
> /* Try the dead server, every 5 seconds */
>
> but the code looks to try for each request more than 5 seconds after the dead 
> server was first noticed.
>
> If I'm correct, does the following (untested) patch make sense?
>
>
>
>
> Index: memcache/apr_memcache.c
> ===
> --- memcache/apr_memcache.c (revision 1389910)
> +++ memcache/apr_memcache.c (working copy)
> @@ -183,8 +183,8 @@
>  #endif
>  /* Try the dead server, every 5 seconds */
>  if (curtime - ms->btime >  apr_time_from_sec(5)) {
> +ms->btime = curtime;
>  if (mc_version_ping(ms) == APR_SUCCESS) {
> -ms->btime = curtime;
>  make_server_live(mc, ms);
>  #if APR_HAS_THREADS
>  apr_thread_mutex_unlock(ms->lock);n
>

It looks correct to me.

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: crypt_r versus macosx

[Jeff Trawick]

On Sun, Sep 9, 2012 at 8:22 AM, Graham Leggett  wrote:
> On 08 Sep 2012, at 5:23 PM, Jeff Trawick wrote:
>
>> Enabling a particular crypto library by default would only be done if
>> --with-crypto was requested.  The global default (no crypto) wouldn't
>> change.  But if you enable the crypto feature you could avoid having
>> to specify a particular implementation, unless the search path had to
>> be overridden.
>
> This sounds sensible. I'd say default --with-openssl and --with-nss to on, 
> and respect the default value of --with-crypto.

Hopefully r1389126 does the right thing...

>
> Regards,
> Graham
> --
>

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: crypt_r versus macosx

[Jeff Trawick]

On Sat, Sep 8, 2012 at 11:18 AM, Graham Leggett  wrote:
> On 8 Sep 2012, at 13:46, Jeff Trawick  wrote:
>
>> Also, on platforms where OpenSSL is installed in a usual location, you only 
>> need
>>
>> --with-crypto --with-openssl
>>
>> Why does it work like this?  APR-Util supports either NSS or OpenSSL
>> libraries (or presumably others in the future) and forces you to
>> choose which one.
>
> At no point are you forced to choose which one, you can choose one, either or 
> both.
>
> A packager would compile both so the end user can choose at runtime which 
> library to use.
>
> A developer would choose both so that the unit tests that test cross 
> compatibility would run.
>
>> Adding "Specify the crypto library using --with-openssl or --with-nss"
>> to the "Crypto was requested but no crypto library was enabled"
>> message will definitely help.
>
> +1.
>
>> Possibly defaulting to --with-openssl if --with-crypto is requested
>> but neither library is specified would be fine.
>
> Ideally have them all defaulted to on, however my understanding is that 
> "default on" wasn't a good thing for crypto code. (would he happy if this 
> proves not to be needed, default on is easier for end users)

Enabling a particular crypto library by default would only be done if
--with-crypto was requested.  The global default (no crypto) wouldn't
change.  But if you enable the crypto feature you could avoid having
to specify a particular implementation, unless the search path had to
be overridden.

>
> Regards,
> Graham
> --
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: crypt_r versus macosx

[Jeff Trawick]

On Sat, Sep 8, 2012 at 8:54 AM, Benson Margulies  wrote:
> A) would you like a bugzilla?

Not necessary...

>
> b) I agree about the default.

I'll give folks a chance to comment about defaulting to OpenSSL before
changing anything.

>
>
>
> On Sat, Sep 8, 2012 at 8:46 AM, Jeff Trawick  wrote:
>>
>> On Sat, Sep 8, 2012 at 8:32 AM, Benson Margulies 
>> wrote:
>> > I've explained it. Is the following a bug?
>> >
>> > Step 1:
>> >
>> >  ./configure --with-apr=/opt/apr-1.4.6 --with-crypto
>> >
>> > include/apu.h:#define APU_HAVE_CRYPTO0
>> >
>> > Step 2:
>> >
>> > ./configure --with-apr=/opt/apr-1.4.6 --with-crypto --with-openssl=/usr
>> >
>> > include/apu.h:#define APU_HAVE_CRYPTO1
>>
>> Also, on platforms where OpenSSL is installed in a usual location, you
>> only need
>>
>> --with-crypto --with-openssl
>>
>> Why does it work like this?  APR-Util supports either NSS or OpenSSL
>> libraries (or presumably others in the future) and forces you to
>> choose which one.
>>
>> Adding "Specify the crypto library using --with-openssl or --with-nss"
>> to the "Crypto was requested but no crypto library was enabled"
>> message will definitely help.
>>
>> Possibly defaulting to --with-openssl if --with-crypto is requested
>> but neither library is specified would be fine.
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: crypt_r versus macosx

[Jeff Trawick]

On Sat, Sep 8, 2012 at 8:32 AM, Benson Margulies  wrote:
> I've explained it. Is the following a bug?
>
> Step 1:
>
>  ./configure --with-apr=/opt/apr-1.4.6 --with-crypto
>
> include/apu.h:#define APU_HAVE_CRYPTO0
>
> Step 2:
>
> ./configure --with-apr=/opt/apr-1.4.6 --with-crypto --with-openssl=/usr
>
> include/apu.h:#define APU_HAVE_CRYPTO1

Also, on platforms where OpenSSL is installed in a usual location, you only need

--with-crypto --with-openssl

Why does it work like this?  APR-Util supports either NSS or OpenSSL
libraries (or presumably others in the future) and forces you to
choose which one.

Adding "Specify the crypto library using --with-openssl or --with-nss"
to the "Crypto was requested but no crypto library was enabled"
message will definitely help.

Possibly defaulting to --with-openssl if --with-crypto is requested
but neither library is specified would be fine.

Re: APR will be non-threaded in cygwin?

[Jeff Trawick]

On Wed, Sep 5, 2012 at 2:17 AM, TROY.LIU 劉春偉  wrote:
> Dear all,
>
>   I failed in opening the thread feature when configuring on Cygwin on
> windows 7.
>
>  I find the configure will disable the enable_threads on cygwin and enable
> it on mingw. Why?

MinGW is a pure Windows API environment, Cygwin is a Unix emulation
environment, so APR's support for threading on one has no implication
for the other.

Cygwin has pthreads but I don't know if anyone has been able to modify
APR to use that successfully.  You could change that code that
disables threads and see what other source changes are required to
utilize the Cygwin pthreads emulation.  I don't know what problems you
might encounter.


>
>   Does apr support thread on Cygwin?
>
>
>
> Configure:
>
> 25144*mingw*)
>
> 25145OSDIR="win32"
>
> 25146enable_threads="system_threads"
>
> 25147eolstr="\\r\\n"
>
> 25148file_as_socket=0
>
> 25149proc_mutex_is_global=1
>
> 25150OBJECTS_PLATFORM='$(OBJECTS_win32)'
>
> 25151;;
>
> 25152*cygwin*)
>
> 25153OSDIR="unix"
>
> 25154enable_threads="no"
>
> 25155eolstr="\\n"
>
>
>
>
>
>
>
> Log:
>
> $ ./configure --prefix=$PWD/../cygwin --enable-threads=yes
>
> checking build system type... i686-pc-cygwin
>
> checking host system type... i686-pc-cygwin
>
> checking target system type... i686-pc-cygwin
>
> Configuring APR library
>
> Platform: i686-pc-cygwin
>
> checking for working mkdir -p... yes
>
> APR Version: 1.4.5
>
> checking for chosen layout... apr
>
> checking for gcc... gcc
>
> checking for C compiler default output file name... a.exe
>
> checking whether the C compiler works... yes
>
> checking whether we are cross compiling... no
>
> checking for suffix of executables... .exe
>
> checking for suffix of object files... o
>
> checking whether we are using the GNU C compiler... yes
>
> checking whether gcc accepts -g... yes
>
> checking for gcc option to accept ISO C89... none needed
>
> checking for a sed that does not truncate output... /usr/bin/sed
>
> Applying APR hints file rules for i686-pc-cygwin
>
>   setting CPPFLAGS to "-DCYGWIN"
>
> (Default will be unix)
>
> checking whether make sets $(MAKE)... yes
>
> checking how to run the C preprocessor... gcc -E
>
> checking for gawk... gawk
>
> checking whether ln -s works... yes
>
> checking for ranlib... ranlib
>
> checking for a BSD-compatible install... /usr/bin/install -c
>
> checking for rm... rm
>
> checking for as... as
>
> checking for cpp... cpp
>
> checking for ar... ar
>
> checking for grep that handles long lines and -e... /usr/bin/grep
>
> checking for egrep... /usr/bin/grep -E
>
> checking for ANSI C header files... yes
>
> checking for sys/types.h... yes
>
> checking for sys/stat.h... yes
>
> checking for stdlib.h... yes
>
> checking for string.h... yes
>
> checking for memory.h... yes
>
> checking for strings.h... yes
>
> checking for inttypes.h... yes
>
> checking for stdint.h... yes
>
> checking for unistd.h... yes
>
> checking minix/config.h usability... no
>
> checking minix/config.h presence... no
>
> checking for minix/config.h... no
>
> checking whether it is safe to define __EXTENSIONS__... yes
>
> checking for library containing strerror... none required
>
> checking whether system uses EBCDIC... no
>
> performing libtool configuration...
>
> checking for a sed that does not truncate output... /usr/bin/sed
>
> checking for ld used by gcc... /usr/i686-pc-cygwin/bin/ld.exe
>
> checking if the linker (/usr/i686-pc-cygwin/bin/ld.exe) is GNU ld... yes
>
> checking for /usr/i686-pc-cygwin/bin/ld.exe option to reload object files...
> -r
>
> checking for BSD-compatible nm... /usr/bin/nm -B
>
> checking how to recognize dependent libraries... file_magic ^x86 archive
> import|^x86 DLL
>
> checking for dlltool... dlltool
>
> checking for objdump... objdump
>
> checking dlfcn.h usability... yes
>
> checking dlfcn.h presence... yes
>
> checking for dlfcn.h... yes
>
> checking for g++... g++
>
> checking whether we are using the GNU C++ compiler... yes
>
> checking whether g++ accepts -g... yes
>
> checking how to run the C++ preprocessor... g++ -E
>
> checking for g77... no
>
> checking for xlf... no
>
> checking for f77... no
>
> checking for frt... no
>
> checking for pgf77... no
>
> checking for cf77... no
>
> checking for fort77... no
>
> checking for fl32... no
>
> checking for af77... no
>
> checking for xlf90... no
>
> checking for f90... no
>
> checking for pgf90... no
>
> checking for pghpf... no
>
> checking for epcf90... no
>
> checking for gfortran... no
>
> checking for g95... no
>
> checking for xlf95... no
>
> checking for f95... no
>
> checking for fort... no
>
> checking for ifort... no
>
> checking for ifc... no
>
> checking for efc... no
>
> checking for pgf95... no
>
> checking for lf95... no
>
> checking for ftn... no
>
> checking whether we are using the GNU Fortran 77 compiler... no
>
> checking whether  accepts -g... no
>
> checking the max

Re: svn commit: r1373078 - in /apr/apr/branches/1.5.x: ./ include/apr_file_io.h include/apr_network_io.h include/apr_thread_proc.h include/apr_want.h

[Jeff Trawick]

On Wed, Aug 15, 2012 at 3:40 AM, Rainer Jung  wrote:
> Hi Jeff,
>
>
> On 14.08.2012 22:48, traw...@apache.org wrote:
>>
>> Author: trawick
>> Date: Tue Aug 14 20:48:12 2012
>> New Revision: 1373078
>>
>> URL: http://svn.apache.org/viewvc?rev=1373078&view=rev
>> Log:
>> Merge parts of r896382 applicable to apr 1.5.x from trunk:
>>
>> Fixes various doxygen usage warnings and minor doxygen errors.
>> Submitted by: Neil Conway 
>>
>> (These changes were committed to the 1.3.x and 1.4.x branches
>> long ago with r896406 and r896402.)
>>
>> Modified:
>>  apr/apr/branches/1.5.x/   (props changed)
>>  apr/apr/branches/1.5.x/include/apr_file_io.h
>>  apr/apr/branches/1.5.x/include/apr_network_io.h
>>  apr/apr/branches/1.5.x/include/apr_thread_proc.h
>>  apr/apr/branches/1.5.x/include/apr_want.h
>>
>> Propchange: apr/apr/branches/1.5.x/
>>
>> --
>>Merged /apr/apr/trunk:r896382
>>
>
> Did you want to commit the following changes:
>
>
>> Modified: apr/apr/branches/1.5.x/include/apr_thread_proc.h
>> URL:
>> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/include/apr_thread_proc.h?rev=1373078&r1=1373077&r2=1373078&view=diff
>>
>> ==
>> --- apr/apr/branches/1.5.x/include/apr_thread_proc.h (original)
>> +++ apr/apr/branches/1.5.x/include/apr_thread_proc.h Tue Aug 14 20:48:12
>> 2012
>> @@ -730,13 +730,13 @@ APR_DECLARE(void) apr_proc_other_child_u
>>* 
>>* rv = apr_proc_wait_all_procs(&proc, &exitcode, &status, APR_WAIT, p);
>>* if (APR_STATUS_IS_CHILD_DONE(rv)) {
>> - * #if APR_HAS_OTHER_CHILD
>> + * \#if APR_HAS_OTHER_CHILD
>>* if (apr_proc_other_child_alert(&proc, APR_OC_REASON_DEATH,
>> status)
>>* == APR_SUCCESS) {
>>* ;  (already handled)
>>* }
>>* else
>> - * #endif
>> + * \#endif
>>* [... handling non-otherchild processes death ...]
>>* 
>>*/
>>
>> Modified: apr/apr/branches/1.5.x/include/apr_want.h
>> URL:
>> http://svn.apache.org/viewvc/apr/apr/branches/1.5.x/include/apr_want.h?rev=1373078&r1=1373077&r2=1373078&view=diff
>>
>> ==
>> --- apr/apr/branches/1.5.x/include/apr_want.h (original)
>> +++ apr/apr/branches/1.5.x/include/apr_want.h Tue Aug 14 20:48:12 2012
>> @@ -30,9 +30,9 @@
>>*
>>* Typical usage:
>>*
>> - *   #define APR_WANT_STRFUNC
>> - *   #define APR_WANT_MEMFUNC
>> - *   #include "apr_want.h"
>> + *   \#define APR_WANT_STRFUNC
>> + *   \#define APR_WANT_MEMFUNC
>> + *   \#include "apr_want.h"
>>*
>>* The appropriate headers will be included.
>>*
>
>
> Probably some debugging leftover?

uhhh, it was all intended...  it matches the corresponding files in
1.4.x and trunk

-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release apr-util 1.5.0

[Jeff Trawick]

On Tue, Aug 7, 2012 at 7:52 PM, Jeff Trawick  wrote:
> On Tue, Aug 7, 2012 at 6:58 PM, olli hauer  wrote:
>> On 2012-08-07 21:09, Stefan Fritsch wrote:
>>> On Tuesday 07 August 2012, Eric Covener wrote:
>>>> On Mon, Aug 6, 2012 at 4:24 PM, Stefan Fritsch 
>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>>>>>
>>>>> It includes many bug fixes and new built-in bcrypt support.
>>>>>
>>>>> Full CHANGES are here:
>>>>> http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>>>>>
>>>>> +/-1
>>>>> [  ]  Release apr-util 1.5.0 as GA
>>>>
>>>> r1357772 moved some code that depended on apu_config.h to
>>>> apr_passwd.c which didn't include it.   On AIX this triggers a
>>>> compile-time error but on other platforms it probably causes APU
>>>> to use crypt() with our own mutex.
>>>
>>> Thanks for catching this. I will T&R 1.5.1 in a few days.
>>>
>>> But if somebody else with a platform that is not Linux, AIX, Netware,
>>> or Windows wants to do some testing first, that would be appreciated.
>>> Maybe Solaris or FreeBSD, anyone?
>>>
>>> It seems on Netware, apr-util 1.5 only builds with the svn version of
>>> APR 1.4 because of some build system changes. Looking at the CHANGES
>>> file, I think releasing apr 1.4.7 as well may be a good idea. If
>>> anyone wants to add some final fixes there, go ahead. In particular,
>>> it would be nice if those Netware build-system changes would get a
>>> CHANGES entry, too.
>>>
>>> Cheers,
>>> Stefan
>>>
>>
>>
>> Test on FreeBSD-8.3 (amd64) apr-1.4.6 + apu-util-1.5.0
>> Let me know if I have to adjust something for the tests
>> eg. special apache build for htpasswd ...
>>
>> teststrmatch: SUCCESS
>> testuri : SUCCESS
>> testuuid: SUCCESS
>> testbuckets : SUCCESS
>> testpass: FAILED 1 of 5
>
> same here on FreeBSD 9 (amd64) with apr-1.5.x HEAD and apr-util-1.5.x HEAD:
>
> freebsd9:FreeBSD:~/svn/apr-util-1.5.x/test$ ./testall -v testpass
> testpass: SUCCESS
> All tests passed.
> freebsd9:FreeBSD:~/svn/apr-util-1.5.x/test$ ./testall -v testpass
> testpass: |Line 36: check for valid password (70024):
> passwords do not match
>
> FAILED 1 of 5
> Failed TestsTotal   FailFailed %
> ===
> testpass5  1 20.00%
>
> (usually fails, sometimes works)

1.4.x fails on FreeBSD 9 too

I think I have a fix to commit shortly -- the crypt() leg was broken
as it released the mutex before it stopped referencing the static
buffer returned by crypt().

>
>> testmd4 : SUCCESS
>> testmd5 : SUCCESS
>> testcrypto  : SUCCESS
>> testdbd : SUCCESS
>> testdate: SUCCESS
>> testmemcache: SUCCESS
>> testxml : SUCCESS
>> testxlate   : SUCCESS
>> testrmm : SUCCESS
>> testdbm : SUCCESS
>> testqueue   : SUCCESS
>> testreslist : SUCCESS
>> Failed TestsTotal   FailFailed %
>> ===
>> testpass5  1 20.00%
>> *** Error code 1
>>
>>
>> --
>> Cheers
>> olli
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release apr-util 1.5.0

[Jeff Trawick]

On Tue, Aug 7, 2012 at 6:58 PM, olli hauer  wrote:
> On 2012-08-07 21:09, Stefan Fritsch wrote:
>> On Tuesday 07 August 2012, Eric Covener wrote:
>>> On Mon, Aug 6, 2012 at 4:24 PM, Stefan Fritsch 
>> wrote:
 Hi,

 Tarballs/zipfiles are at http://apr.apache.org/dev/dist/

 It includes many bug fixes and new built-in bcrypt support.

 Full CHANGES are here:
 http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5

 +/-1
 [  ]  Release apr-util 1.5.0 as GA
>>>
>>> r1357772 moved some code that depended on apu_config.h to
>>> apr_passwd.c which didn't include it.   On AIX this triggers a
>>> compile-time error but on other platforms it probably causes APU
>>> to use crypt() with our own mutex.
>>
>> Thanks for catching this. I will T&R 1.5.1 in a few days.
>>
>> But if somebody else with a platform that is not Linux, AIX, Netware,
>> or Windows wants to do some testing first, that would be appreciated.
>> Maybe Solaris or FreeBSD, anyone?
>>
>> It seems on Netware, apr-util 1.5 only builds with the svn version of
>> APR 1.4 because of some build system changes. Looking at the CHANGES
>> file, I think releasing apr 1.4.7 as well may be a good idea. If
>> anyone wants to add some final fixes there, go ahead. In particular,
>> it would be nice if those Netware build-system changes would get a
>> CHANGES entry, too.
>>
>> Cheers,
>> Stefan
>>
>
>
> Test on FreeBSD-8.3 (amd64) apr-1.4.6 + apu-util-1.5.0
> Let me know if I have to adjust something for the tests
> eg. special apache build for htpasswd ...
>
> teststrmatch: SUCCESS
> testuri : SUCCESS
> testuuid: SUCCESS
> testbuckets : SUCCESS
> testpass: FAILED 1 of 5

same here on FreeBSD 9 (amd64) with apr-1.5.x HEAD and apr-util-1.5.x HEAD:

freebsd9:FreeBSD:~/svn/apr-util-1.5.x/test$ ./testall -v testpass
testpass: SUCCESS
All tests passed.
freebsd9:FreeBSD:~/svn/apr-util-1.5.x/test$ ./testall -v testpass
testpass: |Line 36: check for valid password (70024):
passwords do not match

FAILED 1 of 5
Failed TestsTotal   FailFailed %
===
testpass5  1 20.00%

(usually fails, sometimes works)

> testmd4 : SUCCESS
> testmd5 : SUCCESS
> testcrypto  : SUCCESS
> testdbd : SUCCESS
> testdate: SUCCESS
> testmemcache: SUCCESS
> testxml : SUCCESS
> testxlate   : SUCCESS
> testrmm : SUCCESS
> testdbm : SUCCESS
> testqueue   : SUCCESS
> testreslist : SUCCESS
> Failed TestsTotal   FailFailed %
> ===
> testpass5  1 20.00%
> *** Error code 1
>
>
> --
> Cheers
> olli



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: [VOTE] Release apr-util 1.5.0

[Jeff Trawick]

On Tue, Aug 7, 2012 at 3:09 PM, Stefan Fritsch  wrote:
> On Tuesday 07 August 2012, Eric Covener wrote:
>> On Mon, Aug 6, 2012 at 4:24 PM, Stefan Fritsch 
> wrote:
>> > Hi,
>> >
>> > Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>> >
>> > It includes many bug fixes and new built-in bcrypt support.
>> >
>> > Full CHANGES are here:
>> > http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>> >
>> > +/-1
>> > [  ]  Release apr-util 1.5.0 as GA
>>
>> r1357772 moved some code that depended on apu_config.h to
>> apr_passwd.c which didn't include it.   On AIX this triggers a
>> compile-time error but on other platforms it probably causes APU
>> to use crypt() with our own mutex.
>
> Thanks for catching this. I will T&R 1.5.1 in a few days.
>
> But if somebody else with a platform that is not Linux, AIX, Netware,
> or Windows wants to do some testing first, that would be appreciated.
> Maybe Solaris or FreeBSD, anyone?

BTW, did anyone test on Windows yet?

Re: [VOTE] Release apr-util 1.5.0

[Jeff Trawick]

On Tue, Aug 7, 2012 at 3:09 PM, Stefan Fritsch  wrote:
> On Tuesday 07 August 2012, Eric Covener wrote:
>> On Mon, Aug 6, 2012 at 4:24 PM, Stefan Fritsch 
> wrote:
>> > Hi,
>> >
>> > Tarballs/zipfiles are at http://apr.apache.org/dev/dist/
>> >
>> > It includes many bug fixes and new built-in bcrypt support.
>> >
>> > Full CHANGES are here:
>> > http://apr.apache.org/dev/dist/CHANGES-APR-UTIL-1.5
>> >
>> > +/-1
>> > [  ]  Release apr-util 1.5.0 as GA
>>
>> r1357772 moved some code that depended on apu_config.h to
>> apr_passwd.c which didn't include it.   On AIX this triggers a
>> compile-time error but on other platforms it probably causes APU
>> to use crypt() with our own mutex.
>
> Thanks for catching this. I will T&R 1.5.1 in a few days.
>
> But if somebody else with a platform that is not Linux, AIX, Netware,
> or Windows wants to do some testing first, that would be appreciated.
> Maybe Solaris or FreeBSD, anyone?

I'll try on FreeBSD 9 "soon".

> It seems on Netware, apr-util 1.5 only builds with the svn version of
> APR 1.4 because of some build system changes. Looking at the CHANGES
> file, I think releasing apr 1.4.7 as well may be a good idea. If
> anyone wants to add some final fixes there, go ahead. In particular,
> it would be nice if those Netware build-system changes would get a
> CHANGES entry, too.
>
> Cheers,
> Stefan



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: svn commit: r1369580 - /apr/apr-util/branches/1.5.x/CHANGES

[Jeff Trawick]

On Sun, Aug 5, 2012 at 9:29 AM,   wrote:
> Author: trawick
> Date: Sun Aug  5 13:29:10 2012
> New Revision: 1369580
>
> URL: http://svn.apache.org/viewvc?rev=1369580&view=rev
> Log:
> use standard verbage when pointing to the 1.4.x changes file
>
> remove an entry for a fix which was backported to 1.4.x
> (now the 1.5.x entries are all 1.5.x-specific)

sf, this is just stating the obvious, but before rolling apr-util
1.5.0 be sure to add back all the CHANGES entries from unreleased
apr-util 1.4.2 and 1.4.3

Re: Please confirm the freetds bug in apr-util-1.4.1.tar.gz

[Jeff Trawick]

On Wed, Jul 18, 2012 at 8:47 PM, TROY.LIU �⒋���  wrote:
> Thank you, I will file bug in  http://issues.apache.org/bugzilla/.

I'm sorry if I wasn't clear enough.

You don't need to file a bug for this issue, as I have already
committed your fix.  If you need to file a bug for some future issue,
use http://issues.apache.org/bugzilla/.

Here is your fix in the apr-util 1.4.x branch:

http://svn.apache.org/viewvc?view=revision&revision=1362895

(It is also in trunk and 1.5.x.)

>
> -Original Message-
> From: Jeff Trawick [mailto:traw...@gmail.com]
> Sent: Wednesday, July 18, 2012 7:34 PM
> To: TROY.LIU �⒋���; dev@apr.apache.org
> Subject: Re: Please confirm the freetds bug in apr-util-1.4.1.tar.gz
>
> On Wed, Jul 18, 2012 at 4:38 AM, TROY.LIU �⒋���  
> wrote:
>> Dear all,
>>
>>   I found a bug and don’t know where to file it. Just send the mail to
>> let you know.
>
> Bugs can be filed at http://issues.apache.org/bugzilla/
>
> But in this case I can confirm the bug and will commit your fix shortly.
>
> Thanks!
>
>>
>> In the apr_dbd_freetds.c +630, function freetds_open:
>>
>>
>>
>> sql = apr_palloc (pool, sizeof (apr_dbd_t));  // should be
>> apr_pcalloc, like apr_dbd_pgsql_open.c +1231
>>
>>
>>
>> if calls dbd_freetds_query after freetds_open,  it will fail.
>>
>> static int dbd_freetds_query(apr_dbd_t *sql, int *nrows, const char
>> *query)
>>
>> {
>>
>> if (sql->trans && sql->trans->errnum) {
>>
>> return sql->trans->errnum;
>>
>> }
>>
>> …
>>
>>
>>
>> Please confirm this issue.
>>
>>
>>
>> http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/dbd/apr_dbd_f
>> reetds.c?view=markup
>>
>> http://svn.apache.org/viewvc/apr/apr-util/branches/1.5.x/dbd/apr_dbd_f
>> reetds.c?view=markup
>>
>>
>>
>>
>>
>>
>>
>> Best Regards
>>
>> Chunwei Liu
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Build of libapritil-1.lib failed on Windows using VS2008

[Jeff Trawick]

On Mon, Jul 16, 2012 at 1:27 PM, Alona Rossen  wrote:
>
>
> Hello,
>
>
>
> Build of libapritil-1.lib failed on Windows using VS2008:
>
>
>
> 1>Linking...
>
> 1>   Creating library Debug\libaprutil-1.lib and object
> Debug\libaprutil-1.exp
>
> 1>apr_dbd.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12
>
> 1>apr_reslist.obj : error LNK2019: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12 referenced in function _reslist_cleanup

I don't have much experience with debugging problems building apr*
with Visual Studio, but I see that all these unresolved external
symbols are from libapr.

Please explain the steps you followed to build apr and apr-util, and
hopefully someone will have an idea of what was missed.

>
> 1>apr_brigade.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12
>
> 1>apr_buckets_alloc.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12
>
> 1>apr_buckets_mmap.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12
>
> 1>apr_buckets_pool.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_kill@12
>
> 1>apr_xml.obj : error LNK2019: unresolved external symbol
> __imp__apr_pool_cleanup_register@16 referenced in function _start_handler
>
> 1>apr_reslist.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_thread_pool.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>sdbm.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>xlate.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_dbd.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_dbm.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apu_dso.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_queue.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_brigade.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_buckets_alloc.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_buckets_mmap.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_buckets_pool.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_register@16
>
> 1>apr_xml.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_reslist.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_thread_pool.obj : error LNK2019: unresolved external symbol
> __imp__apr_pool_cleanup_null referenced in function _pop_task
>
> 1>sdbm.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>xlate.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_dbd.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_dbm.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apu_dso.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_queue.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_brigade.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_buckets_alloc.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_buckets_mmap.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_buckets_pool.obj : error LNK2001: unresolved external symbol
> __imp__apr_pool_cleanup_null
>
> 1>apr_xml.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_rmm.obj : error LNK2019: unresolved external symbol
> __imp__apr_palloc@8 referenced in function _apr_rmm_init@20
>
> 1>apr_thread_pool.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_strmatch.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>xlate.obj : error LNK2001: unresolved external symbol __imp__apr_palloc@8
>
> 1>apr_ldap_url.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_memcache.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_queue.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_reslist.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_brigade.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_dbd.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_dbm_sdbm.obj : error LNK2001: unresolved external symbol
> __imp__apr_palloc@8
>
> 1>apr_hooks.obj : error LNK2001: unresolved external symbol
> __imp__apr_pa

Re: [VOTE] Release apr-util 1.4.2

[Jeff Trawick]

On Sun, Mar 25, 2012 at 4:36 PM, Graham Leggett  wrote:
> Hi all,
>
> Tarballs/zipballs are at 
> http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>
> Fixed in apr-util is the static build of the apr_crypto interface. Full 
> CHANGES are here:
> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.2/CHANGES
>
> +/-1
> [  ]  Release apr-util 1.4.2 as GA

I didn't find a statement on the mailing list (bad search?), but
obviously 1.4.2 is not being released.

Re: Please confirm the freetds bug in apr-util-1.4.1.tar.gz

[Jeff Trawick]

On Wed, Jul 18, 2012 at 7:34 AM, Jeff Trawick  wrote:
> On Wed, Jul 18, 2012 at 4:38 AM, TROY.LIU �⒋���  
> wrote:
>> Dear all,
>>
>>   I found a bug and don’t know where to file it. Just send the mail to let
>> you know.
>
> Bugs can be filed at http://issues.apache.org/bugzilla/
>
> But in this case I can confirm the bug and will commit your fix shortly.

Committed now to trunk and to the 1.4.x and 1.5.x branches...

>
> Thanks!
>
>>
>> In the apr_dbd_freetds.c +630, function freetds_open:
>>
>>
>>
>> sql = apr_palloc (pool, sizeof (apr_dbd_t));  // should be  apr_pcalloc,
>> like apr_dbd_pgsql_open.c +1231
>>
>>
>>
>> if calls dbd_freetds_query after freetds_open,  it will fail.
>>
>> static int dbd_freetds_query(apr_dbd_t *sql, int *nrows, const char *query)
>>
>> {
>>
>> if (sql->trans && sql->trans->errnum) {
>>
>> return sql->trans->errnum;
>>
>> }
>>
>> …
>>
>>
>>
>> Please confirm this issue.
>>
>>
>>
>> http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/dbd/apr_dbd_freetds.c?view=markup
>>
>> http://svn.apache.org/viewvc/apr/apr-util/branches/1.5.x/dbd/apr_dbd_freetds.c?view=markup
>>
>>
>>
>>
>>
>>
>>
>> Best Regards
>>
>> Chunwei Liu
>>
>>
>
>
>
> --
> Born in Roswell... married an alien...
> http://emptyhammock.com/



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Please confirm the freetds bug in apr-util-1.4.1.tar.gz

[Jeff Trawick]

On Wed, Jul 18, 2012 at 4:38 AM, TROY.LIU �⒋���  wrote:
> Dear all,
>
>   I found a bug and don’t know where to file it. Just send the mail to let
> you know.

Bugs can be filed at http://issues.apache.org/bugzilla/

But in this case I can confirm the bug and will commit your fix shortly.

Thanks!

>
> In the apr_dbd_freetds.c +630, function freetds_open:
>
>
>
> sql = apr_palloc (pool, sizeof (apr_dbd_t));  // should be  apr_pcalloc,
> like apr_dbd_pgsql_open.c +1231
>
>
>
> if calls dbd_freetds_query after freetds_open,  it will fail.
>
> static int dbd_freetds_query(apr_dbd_t *sql, int *nrows, const char *query)
>
> {
>
> if (sql->trans && sql->trans->errnum) {
>
> return sql->trans->errnum;
>
> }
>
> …
>
>
>
> Please confirm this issue.
>
>
>
> http://svn.apache.org/viewvc/apr/apr-util/branches/1.4.x/dbd/apr_dbd_freetds.c?view=markup
>
> http://svn.apache.org/viewvc/apr/apr-util/branches/1.5.x/dbd/apr_dbd_freetds.c?view=markup
>
>
>
>
>
>
>
> Best Regards
>
> Chunwei Liu
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: Apache BarCamp Washington D.C

[Jeff Trawick]

On Tue, May 1, 2012 at 2:00 PM, William A. Rowe Jr.  wrote:
> I hope many of you already saw this and might be considering attending
> to present whatever short topics you would like during the BarCamp about
> our projects!
>
> I'd asked and there is no plan -yet- for any Hackathon activity, but Tim
> indicated it might be able to happen.  Would anyone be up for a Hackathon
> of httpd and apr topics the day before, or after, or even during the camp?

I'm interested, but the potential for joining is on the day after.

>
>
>
>  Original Message 
> Subject: Apache BarCamp Washington D.C
> Date: Mon, 30 Apr 2012 07:26:22 -0400
> From: Tim Williams 
> To: committ...@apache.org
>
> Hi Committers,
>
> The first Apache BarCamp Washington, D.C. will be held on May 19th.
> If you will be in or around the Washington, D.C. area at that time,
> sign up and join us!
>
> As with all Apache BarCamps, there will be a mix of Apache and
> non-Apache talks given based on who comes and the topics that interest
> them - with an emphasis on sharing knowledge and having a fun time.
> For more details and/or to sign up, please take a look at our event
> site[1].  If you have specific questions feel free to email the
> planning group .
>
> We are also wanting a few more sponsors, so if the D.C. market is
> interesting to your company and you'd like to find out some sponsoring
> details, contact us at .
>
> Otherwise, if you can't join us in the Washington D.C. area, but
> you're interested in helping run an Apache BarCamp or Hackathon in
> your home town, then get your questions answered at
> 
>
> Thanks,
> --tim
>
> [1] - http://events.apache.org/event/2012/barcamp-dc/
>
>



-- 
Born in Roswell... married an alien...
http://emptyhammock.com/

Re: A bug with httpd-2.4.2 Win-x64

[Jeff Trawick]

On Mon, Apr 16, 2012 at 8:32 AM, Bing Swen  wrote:
> Hi,
>
> After building the httpd-2.4.2 x64 binaries with VS2010, I encountered a 
> runtime error in the module libhttpd.dll, which alerts that a heap corruption 
> occurred at somewhere:
>        file D:\_bsDev\KSE\httpd-2.4.2\server\config.c
>        line 680:
>                 free(ap_module_short_names[m->module_index]);
>
> The free() call always led to heap corruption like this:
>                        HeapFree(_crtheap, 0, pBlock);
>                        // access error with pBlock  == NULL.
>
> My temp solution is commenting off this single line to get httpd.exe run. 
> Please verify if it is a bug.

Please post to the d...@httpd.apache.org instead of to this APR list,
as the symptom is closely related to httpd code.

Re: backports/merges

[Jeff Trawick]

On Mon, Apr 9, 2012 at 2:34 PM, Jeff Trawick  wrote:
> On Mon, Apr 9, 2012 at 2:17 PM, William A. Rowe Jr.  
> wrote:
>> On 4/9/2012 11:04 AM, Stefan Fritsch wrote:
>>> On Monday 09 April 2012, Rainer Jung wrote:
>>>>> Do you disagree with the procedure and/or my attempt to describe
>>>>> the "normal" way this is handled?
>>>>
>>>> No, I agree and I think it is more useful to include the CHANGES
>>>> entry  in the backport commit than to split it in a second commit.
>>>> At least that's what I tried to do in the past influenced by
>>>> following the list and commit messages. Sometimes the CHANGES
>>>> entry either is forgotten during the backport commit or postponed
>>>> by a differing personal preference and is then added soon as a
>>>> separate commit which I think is less useful but still acceptable.
>>>
>>> +1
>>
>> +1; and ++1 for formalizing this at apr.a.o/dev/
>
> I'll do that.  (No, really!)

Wow, I actually found a round tuit for something I said I'd do :)

Re: backports/merges

[Jeff Trawick]

On Mon, Apr 9, 2012 at 2:17 PM, William A. Rowe Jr.  wrote:
> On 4/9/2012 11:04 AM, Stefan Fritsch wrote:
>> On Monday 09 April 2012, Rainer Jung wrote:
 Do you disagree with the procedure and/or my attempt to describe
 the "normal" way this is handled?
>>>
>>> No, I agree and I think it is more useful to include the CHANGES
>>> entry  in the backport commit than to split it in a second commit.
>>> At least that's what I tried to do in the past influenced by
>>> following the list and commit messages. Sometimes the CHANGES
>>> entry either is forgotten during the backport commit or postponed
>>> by a differing personal preference and is then added soon as a
>>> separate commit which I think is less useful but still acceptable.
>>
>> +1
>
> +1; and ++1 for formalizing this at apr.a.o/dev/

I'll do that.  (No, really!)

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Jeff Trawick]

On Mon, Apr 9, 2012 at 12:56 PM, William A. Rowe Jr.
 wrote:
> To the list; I'm sorry about the tone of this discussion. I'm sorry
> about the hostility embedded in my response. For the list participants,
> Branko and Jeff are right, it doesn't need to be here.  I'd respond to
> one point Stefan raises and then have nothing more productive to add
> to this dialog.
>
>
> On 4/9/2012 11:03 AM, Stefan Fritsch wrote:
>>
>> Bill, I think your criticism is completely out of proportion to the
>> issue at hand, namely not including the trunk revision number in the
>> log message. Other commiters produce broken log messages now and then,
>> too.
>
> We aren't discussing whether the original commit number belongs, because
> the project adopted the convention of including the original commit number
> and we have thousands of backports to document that practice.  We aren't
> discussing whether automake solves problems, because the projects' committers
> have experiences that it introduces more portability issues than it solves
> in this very broad portability scope when extended beyond the use of gnu
> toolchains.  We aren't discussing if mistakes will or won't be made, because
> we know they will be...
>
> I'm the first to acknowledge hundreds of mistakes out of thousands of
> commits I've made here and on other ASF project repositories.  The modulo
> is this; if you or any other list participant corrects me, I fix it.  If
> one of you correct it for me, I thank you.  If I argue the point and then
> you prove me wrong, I thank you after I apologize.
>
> I don't observe a similar level of courtesy from this committer towards
> others at this project.  I'm largely ignoring that committer's code, in
> the hopes that he responds better to other committers' feedback and
> criticism, and don't enter technical conversations, because I don't want
> to distract and to rub him the wrong way.  I understand our lingering
> animosity, and accept part of the responsibility for our ineffective
> relationship.
>
> But despite my hopes, I don't see him responding better to criticism and
> correction by other colleagues either, and that is why I'm concerned.
> My email yesterday was in direct response to the pattern of intractable
> and oppositional-defiant participation which makes the very act of
> technical discussion impossible.  I'd been disconnected, watched a very
> long thread about nothing escalate for no good reason.  I took away from
> that thread a theme of "The Project is Wrong, I'm Right".
>
> I'm immediately answering your message that yes, my post was unreasonably
> harsh and I'm sorry for poisoning the conversation.  I'd like to see a
> return to the mode where all arguments are based in substantive, technical
> justification, and the mode where precedent and the choices that were made
> before by the project as a whole are given the courtesy of a presumption
> that they were well considered and are serving our fellow project members
> well.  I'd like a return to raising corrections that don't escalate to
> belligerent argument where there is no point to an argument.
>
> I don't know if that will happen; certainly I'm sometimes part of the
> problem, so I can say nothing more about this.  I hope others such as you
> and Jeff can more gently redirect colleagues when folks descend into being
> obstinate, and head off such escalations.  I can't have a part in that
> discussion because I lack the diplomacy to have a productive impact.
>
> Again, to you and the list, sorry for my tone.  I can't find an apology
> for my frustration, however, and simply hope for the situation to improve.

FWLIW, I think the opportunity for learning in this thread was
compromised from the start due to the fact that the initial objection
was out of sync with normal practice.

I believe that more and different people need to be involved in such
discussions in order to better communicate group understanding (or
occasional lack thereof) and even to point out that one behavior or
another is making it harder to resolve the problem at hand or to work
together in general.

modes of discussion

[Jeff Trawick]

Some of the behavior here is embarrassing.  Yelling about not
following procedures that nobody else even follows as stated,
threatening, whining, crudity or at least making fun of objections to
crudity, extreme defensiveness, etc. do not reflect well on us or our
ability to do anything together.  Even without staking out extreme
positions, attempts to communicate concerns in the simplest manner can
elicit very strong emotional reactions which feed the frenzy.  Some
less active participants must see it as a poor statement on the human
condition that there can be such fireworks about such a simple little
project.

We need to try harder to avoid the extreme offensive and defensive
positions and acknowledge that e-mail is a limited tool in the best of
circumstances, and that some of us are enigmas to each other even in
the best of circumstances.

backports/merges

[Jeff Trawick]

Perhaps it is just my nature to disagree with everybody when there is
some contentious discussion.  Or just possibly it is my nature to try
to pull apart what was discussed (or yelled), throw away the most
extreme aspects, and see if there is anything to agree on.  (Even in
the absence of past success at doing so :( )

Procedure:

Below is what I observe and practice for changes made to the stable
branches, and I believe this is clearly the widespread, accepted
pattern.  Furthermore I believe it is simple enough that it can be
followed without demands for documentation, even though such
documentation would be fine.

Commit to trunk.
Commit to 1.9.x, 1.8.x, 1.7.x, etc. down to the actively maintained
stable branch. In cases where the actively maintained stable branch
has recently changed, it is up to the committer to decide whether to
commit to the previous actively maintained stable branch.  (There is
at least limited value in having the project decide what the patch for
some branch is even if there are no clear plans to release it.)

Commit messages for the branches always explicitly reference the trunk
revision, not relying on mergeinfo, which does not show up in normal
views of revision history.

Modifications expected to remain only in trunk, at least for some
time, should be accompanied by a CHANGES entry in trunk, if
appropriate.  CHANGES entries are appropriate for user-visible changes
to a previously released feature or for user-visible feature
additions.

When committing to previously released branches, the CHANGES entry
should be part of the commit, whether or not it was part of the trunk
commit.  (A CHANGES entry is commonly omitted from the trunk commit if
a backport will be performed almost immediately.)

Do you disagree with the procedure and/or my attempt to describe the
"normal" way this is handled?

a. Did I misrepresent the project norms?  Please follow up to this thread.
b. Do you believe it should be done differently, irregardless of
project norms?  Please propose something different in a new thread.

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Jeff Trawick]

On Sun, Apr 1, 2012 at 5:13 PM, Greg Stein  wrote:
> On Sun, Apr 1, 2012 at 17:04, Jeff Trawick  wrote:
>> On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein  wrote:
>>> On Sun, Apr 1, 2012 at 11:23,   wrote:
>>>> Author: minfrin
>>>> Date: Sun Apr  1 15:23:45 2012
>>>> New Revision: 1308135
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1308135&view=rev
>>>> Log:
>>>> Backport:
>>>> apr_crypto: Ensure the *driver variable is initialised when a statically
>>>> compiled library is initialised for the first time.
>>>>
>>>> Modified:
>>>>    apr/apr-util/branches/1.4.x/   (props changed)
>>>>    apr/apr-util/branches/1.4.x/CHANGES
>>>>    apr/apr-util/branches/1.4.x/crypto/apr_crypto.c
>>>>
>>>> Propchange: apr/apr-util/branches/1.4.x/
>>>> --
>>>>  Merged /apr/apr/trunk:r1308131
>>>
>>> -131 has no edit to CHANGES.
>>>
>>> When performing backports, you should commit *just* the backport. If
>>> you want to make other changes, then keep them in a separate commit.
>>>
>>> Combining changes like this is poor branch policy. It means that we
>>> can no longer trust that a backport is *JUST* the backport. We have to
>>> investigate to determine whether other changes were made in the
>>> commit.
>>
>> That adds an extra step to looking at the code changes for a CHANGES
>> entry, if indeed the merger/backporter remembered to list the code
>> change in the CHANGES commit.  (Otherwise it is more painful.)
>
> I'm not sure that I follow that statement.
>
> My point is: if you do a backport of a commit, then do *just* the
> backport. Throwing other work into that commit leads to insanity.

I agree that throwing in unrelated modifications leads to insanity.
(But our definition of unrelated probably differs; fixing CHANGES in
the commit has not led to insanity so far and has avoided the
potential that the subsequent CHANGES commit didn't reference the code
change.)

>> I guess you mean that the "trust" part comes not from backports in
>> general but only from a a "touchless" merge.  Generally a "backport"
>> may require minor changes to reflect other differences in the branch.
>
> For that kind of problem, in Subversion, we create a
> branch-of-the-branch then backport the revision, then make the
> necessary edits to make the backport conform to the branch. Thus, when
> we touch branches/1.N.x, we are doing a simple backport merge. Again:
> no other changes in that revision beyond JUST the backport.
>
> So yes: I'm saying touchless merges are the proper way to manage branches.

Then see what kind of buy-in you get for that in a new thread.

> These two backports today were reckless. Both of them were not
> "touchless" to use your term. And worse: that fact was not documented
> in the log message. "Backport" is all it said. Not what revision was
> backported. Not that other changes were made beyond that
> (unidentified) revision.

I agree that a log message is busted if it doesn't mention the trunk
revision(s) for the code.  (I don't know how the mergeinfo shows up
when looking at the revisions later.)

> I can maybe understand a policy that says CHANGES should be edited
> directly on the branch (since, at this point, trunk CHANGES and branch
> CHANGES are completel dissimilar). But those edits should not be part
> of backport merges.

shrug

Re: svn commit: r1308135 - in /apr/apr-util/branches/1.4.x: ./ CHANGES crypto/apr_crypto.c

[Jeff Trawick]

On Sun, Apr 1, 2012 at 4:55 PM, Greg Stein  wrote:
> On Sun, Apr 1, 2012 at 11:23,   wrote:
>> Author: minfrin
>> Date: Sun Apr  1 15:23:45 2012
>> New Revision: 1308135
>>
>> URL: http://svn.apache.org/viewvc?rev=1308135&view=rev
>> Log:
>> Backport:
>> apr_crypto: Ensure the *driver variable is initialised when a statically
>> compiled library is initialised for the first time.
>>
>> Modified:
>>    apr/apr-util/branches/1.4.x/   (props changed)
>>    apr/apr-util/branches/1.4.x/CHANGES
>>    apr/apr-util/branches/1.4.x/crypto/apr_crypto.c
>>
>> Propchange: apr/apr-util/branches/1.4.x/
>> --
>>  Merged /apr/apr/trunk:r1308131
>
> -131 has no edit to CHANGES.
>
> When performing backports, you should commit *just* the backport. If
> you want to make other changes, then keep them in a separate commit.
>
> Combining changes like this is poor branch policy. It means that we
> can no longer trust that a backport is *JUST* the backport. We have to
> investigate to determine whether other changes were made in the
> commit.

That adds an extra step to looking at the code changes for a CHANGES
entry, if indeed the merger/backporter remembered to list the code
change in the CHANGES commit.  (Otherwise it is more painful.)

I guess you mean that the "trust" part comes not from backports in
general but only from a a "touchless" merge.  Generally a "backport"
may require minor changes to reflect other differences in the branch.

Re: [VOTE] Release apr-util 1.4.2

[Jeff Trawick]

On Fri, Mar 30, 2012 at 4:33 PM, Jeff Trawick  wrote:
> On Sun, Mar 25, 2012 at 4:36 PM, Graham Leggett  wrote:
>> Hi all,
>>
>> Tarballs/zipballs are at 
>> http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>>
>> Fixed in apr-util is the static build of the apr_crypto interface. Full 
>> CHANGES are here:
>> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.2/CHANGES
>>
>> +/-1
>> [  ]  Release apr-util 1.4.2 as GA
>
> Hopefully I can test tomorrow.

[+1]  Release apr-util 1.4.2 as GA

I tested on Linux only, but a diff of the tarball and zipball against
1.4.1 didn't show any areas of concern.

Re: [VOTE] Release apr-util 1.4.2

[Jeff Trawick]

On Sun, Mar 25, 2012 at 4:36 PM, Graham Leggett  wrote:
> Hi all,
>
> Tarballs/zipballs are at 
> http://apr.apache.org/dev/dist/autoconf-2.68+libtool-2.4.2/.
>
> Fixed in apr-util is the static build of the apr_crypto interface. Full 
> CHANGES are here:
> https://svn.apache.org/repos/asf/apr/apr-util/tags/1.4.2/CHANGES
>
> +/-1
> [  ]  Release apr-util 1.4.2 as GA

Hopefully I can test tomorrow.

Re: buildbot failure in ASF Buildbot on apr-util-branch-1.4-fbsd

[Jeff Trawick]

On Sat, Mar 10, 2012 at 8:28 AM,   wrote:
> The Buildbot has detected a new failure on builder apr-util-branch-1.4-fbsd 
> while building ASF Buildbot.
> Full details are available at:
>  http://ci.apache.org/builders/apr-util-branch-1.4-fbsd/builds/44
>
> Buildbot URL: http://ci.apache.org/
>
> Buildslave for this Build: bb-fbsd
>
> Build Reason: scheduler
> Build Source Stamp: [branch apr/apr-util/branches/1.4.x] 1299198
> Blamelist: trawick
>
> BUILD FAILED: failed compile_2
>
> sincerely,
>  -The Buildbot

It says the only update was my tweak to STATUS and the failure was

"Makefile", line 50: Could not find
/usr/home/buildbot/slave6/apr-util-branch-1.4-fbsd/build/build/rules.mk
make: fatal errors encountered -- cannot continue

Sunspot activity?

Re: APR and "portability" issues - /usr/include gets skipped by configure when apr is external

[Jeff Trawick]

On Thu, Mar 1, 2012 at 7:55 PM, Michael Felt  wrote:
> Call it innocence, call it naive, call it whatever - but APR is an obstacle
> to be overcome. There is documentation, but lacks an overview of what/how
> apr is used.
> X pages long list of variables does not help prepare one (read me if you
> will) for proper usage.
>
> CASE: built apr, apr-util, httpd on separate system. Want to verify process
> used to create build on another system. Unfortunately, apr has undefined
> variables so cannot build in second environment - install APR and APR-UTIL
> packaged in previous environment. Insert extra files in /usr/include same as
> on original system.
>
> Start configure - runs well until zlib is needed (copy files to
> /usr/include, per above and compile conftest.c successfully). Run configure
> again, still fails.
> My guess, after looking at the log output is that while /usr/include/zlib.h
> was found and used on the original system now "configure" is only using the
> /opt/include
> where the files are not located.
>
> Request: please think about the basic documentation - right now if you
> follow the documentation link the first page is one that seems to be "there
> is no documentation".
> The other navigation items show otherwise - but what are all these
> functions, modules, etc. And how do they explain that configure does not
> work.
>
> p.s. the first hint that something was wrong was the return of a static name
> for a compiler (was cc - xlc was better), but now working with gcc - so
> everything fails.
> -- I have learned that apr and apr-util are largely static - executable
> caching of variables - is that one way of describing how it works?
>
> Note: I have no idea of what is in libapr or libaprutil - but I am concerned
> that they are not going to be portable enough to use across different
> hardware/os platforms
> even those platforms are binary compatible. Also - maybe - the problems are
> limited to apr-1-config and apu-1-config. Here is hoping!
>
> Note: 6000-ibm-aix: bad number ... Is this because this is an AIX 7.1
> system? It moves on, thankfully, but thought this was the cause initially.
>
> ==
> ./configure[5865]: 6000-ibm-aix: bad number
> + cp conftest.c mytest.c
> + ac_fn_c_try_link 11027
> + print -r -- configure:11035: result: not found
> + 1>& 5
> + print -r -- not found
> + 1>& 6
> + enable_deflate=no
> + INCLUDES=-I$(top_builddir)/srclib/pcre -I. -I$(top_srcdir)/os/$(OS_DIR)
> -I$(top_srcdir)/server/mpm/$(MPM_SUBDIR_NAME) -I$(top_srcdir)/modules/http
> -I$(top_srcdir)/modules/filters -I$(top_srcdir)/modules/proxy
> -I$(top_srcdir)/include -I$(top_srcdir)/modules/generators
> -I$(top_srcdir)/modules/mappers -I$(top_srcdir)/modules/database
> -I/opt/include -I/usr/include/openssl/include
> + LDFLAGS=  -L/usr/include/openssl/lib
> + rm -f core conftest.err conftest.o conftest conftest.c
> + test x-lm  -lz = x-lz
> + apr_new_bugger=
> + apr_removed=0
> + test x-lm != x-lz
> + apr_new_bugger= -lm
> + test x-lz != x-lz
> + apr_removed=1
> + test 1 = 1
> + test x != xyes
> + echo   removed "-lz" from LIBS
> + LIBS= -lm
> + CPPFLAGS=
> + print -r -- configure:11066: checking whether to enable mod_deflate
> + 1>& 5
> + print -rn -- checking whether to enable mod_deflate...
> + 1>& 6
> + test no = no
> + test yes = no
> + as_fn_error mod_deflate has been requested but can not be built due to
> prerequisite failures 11072 5
> configure: error: mod_deflate has been requested but can not be built due to
> prerequisite failures
> + exit_status=1
> + 1>& 5
> ===

That's way too much to grok :)

What you're showing above is part of the httpd build, not part of apr.
 zlib isn't used by apr.  apr and apr-util are code -- networking,
management of private and shared memory, files, etc. -- but I guess if
you're having trouble building it the autoconf side may seem to be the
whole thing.

httpd uses some autoconf macros from APR and they use the "apr_" prefix.

This is the apr list, so why not take the opportunity to make sure apr
and apr-util are building as we expect...

apr 1.4.6:

CC=xlc_r ./configure --prefix=whatever && make && make install && make test

Proceed with apr-util 1.4.1:

Similar to the above, but point to your apr using the --with-apr
parameter to configure

Does that work on all your systems, substituting the desired compiler
front-end for xlc_r?  Do you need to try other configure arguments for
one reason or another?

I don't know about the AIX level support/that error message...  Does
this display something reasonable?

build/config.sub `build/config.guess`

Re: Still #ifdef WIN64 in APR

[Jeff Trawick]

On Thu, Mar 1, 2012 at 8:23 AM, Mladen Turk  wrote:
> On 03/01/2012 01:19 PM, Jeff Trawick wrote:
>>
>>
>> Regardless of the APR_SIZEOF_VOIDP issue, it should be _WIN64 in the
>> .c/.h code.  I'll commit that.  I guess the attribution to use is the
>> e-mail address in bug 49155.
>>
>
> _WIN64 is defined by cl.exe (same as WIN32/_WIN32)
>
> WIN64 should be defined by make files, but agreed that's just
> needless duplication. In case mingw64 doesn't defines _WIN64, this should
> be added to configure.

apparently it does (see the recap in the second post at
http://groups.google.com/group/mpir-devel/browse_thread/thread/e8c4aa0e4f4daafd?pli=1)

I don't have 64-bit MINGW set up locally to confirm, but that's good
enough for me.

Re: Still #ifdef WIN64 in APR

[Jeff Trawick]

On Thu, Mar 1, 2012 at 6:15 AM, Steffen  wrote:
> In APR 1.4.6 there is still a typo in the statements, causes crashes HTTPD
> in eg. setting on logging in mod_rewrite.
>
> In shm.c and apr.hw
>
> #ifdef WIN64
>
> Sould be:
>
> #ifdef _WIN64
>
>
>
> Steffen

Does this work for you?

http://svn.apache.org/viewvc?view=revision&revision=1295535

(I'll move the fix back to 1.5 and 1.4 branches and retarget the bug to apr.)



-- 
Born in Roswell... married an alien...

Re: Still #ifdef WIN64 in APR

[Jeff Trawick]

On Thu, Mar 1, 2012 at 7:04 AM, Eric Covener  wrote:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=49155 says:
>
> APR_SIZEOF_VOIDP isn't defined as 8 because of the "#ifdef WIN64" statement
> preceding "#define APR_SIZEOF_VOIDP 8" in the apr.hw file. It is supposed be
> "#ifdef _WIN64". There is another "#ifdef WIN64" in apr.hw which should also 
> be
> changed to "#ifdef _WIN64".

See also http://stackoverflow.com/a/1648031

So the fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=40758 was bad?

We also have this reference to "WIN64":

./libapr.rc:#if defined(WINNT) || defined(WIN64)

If the post I found is correct, any such checks will work only because
the project has defined the symbol.  However, I don't see WIN64
getting defined so I don't know why it is checked.  (And we seem to
define WINNT for 64-bit builds.)

Regardless of the APR_SIZEOF_VOIDP issue, it should be _WIN64 in the
.c/.h code.  I'll commit that.  I guess the attribution to use is the
e-mail address in bug 49155.


> -- Forwarded message --
> From: Steffen 
> Date: Thu, Mar 1, 2012 at 6:15 AM
> Subject: Still #ifdef WIN64 in APR
> To: d...@httpd.apache.org
>
>
> In APR 1.4.6 there is still a typo in the statements, causes crashes
> HTTPD in eg. setting on logging in mod_rewrite.
>
> In shm.c and apr.hw
>
> #ifdef WIN64
>
> Sould be:
>
> #ifdef _WIN64
>
>
>
> Steffen
>
>
> --
> Eric Covener
> cove...@gmail.com



-- 
Born in Roswell... married an alien...

Re: Makefile.win install target does not install all necessary headers

[Jeff Trawick]

On Mon, Feb 27, 2012 at 9:13 AM, Mat Booth  wrote:
> Hi all,
>
> When using the install target of Makefile.win on Windows, I noticed
> that it does not install all the headers necessary for using the
> platform specific features of APR. Please see the patch to fix it
> below.

These aren't APIs so they're not supposed to be installed.  (Using
httpd on Windows with out of tree apr by any chance?)

>
>
> --- Makefile.win.orig   2012-02-27 13:54:16.5 +
> +++ Makefile.win        2012-02-27 13:56:07.90625 +
> @@ -161,11 +161,15 @@
>        @if NOT EXIST "$(PREFIX)\."             mkdir "$(PREFIX)"
>        @if NOT EXIST "$(PREFIX)\bin\."         mkdir "$(PREFIX)\bin"
>        @if NOT EXIST "$(PREFIX)\include\."     mkdir "$(PREFIX)\include"
> +       @if NOT EXIST "$(PREFIX)\include\arch\."        mkdir 
> "$(PREFIX)\include\arch"
> +       @if NOT EXIST "$(PREFIX)\include\arch\win32\."  mkdir
> "$(PREFIX)\include\arch\win32"
>        @if NOT EXIST "$(PREFIX)\lib\."         mkdir "$(PREFIX)\lib"
>        copy CHANGES "$(PREFIX)\APR-CHANGES.txt" <.y
>        copy LICENSE "$(PREFIX)\APR-LICENSE.txt" <.y
>        copy NOTICE  "$(PREFIX)\APR-NOTICE.txt"  <.y
>        xcopy include\*.h               "$(PREFIX)\include\" /d < .a
> +       xcopy include\arch\*.h          "$(PREFIX)\include\arch\" /d < .a
> +       xcopy include\arch\win32\*.h    "$(PREFIX)\include\arch\win32\" /d < 
> .a
>        copy $(LIBSOSPATH)\apr-1.lib            "$(PREFIX)\lib\" <.y
>        copy $(LIBSOSPATH)\apr-1.pdb            "$(PREFIX)\lib\" <.y
>        copy $(LIBSOSPATH)\aprapp-1.lib         "$(PREFIX)\lib\" <.y
>
>
>
> Best regards,
> Mat
>
> --
> Mat Booth
> Software Engineer
> WANdisco, Inc.
> http://www.wandisco.com



-- 
Born in Roswell... married an alien...

Re: [VOTE] Release apr 1.4.6

[Jeff Trawick]

On Tue, Feb 7, 2012 at 6:33 PM, Bojan Smojver  wrote:
> Tarballs/zipballs are at http://apr.apache.org/dev/dist/.
>
> Various fixes in there, including hash randomisation, so give it a good
> bashing.
>
> Please give your +1/-1:

[+1]  Release apr 1.4.6 as GA

Tested here with Visual C++ 2008 Express Edition; no apparent
build/test regression from 1.4.5 to 1.4.6

Re: [VOTE] Release apr 1.4.6

[Jeff Trawick]

On Tue, Feb 7, 2012 at 6:33 PM, Bojan Smojver  wrote:
> Tarballs/zipballs are at http://apr.apache.org/dev/dist/.

FWIW I plan to review/test later in the day.  Thanks for RM-ing.

(I only bothered to say that since there's not any activity in this
thread yet, and I understand that svn needs the release.)

Re: Version of autoconf for releases?

[Jeff Trawick]

On Tue, Feb 7, 2012 at 5:03 PM, Bojan Smojver  wrote:
> On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
>> Using the slightly patched tool(s) from Fedora seems like a pain for
>> others to reproduce exactly, whereas anyone can install autotools of
>> arbitrary versions on arbitrary non-Windows machines in just a few
>> minutes
>
> So, you want me to keep the vanilla libtool 2.2.4 (which is giving
> warnings) as well, or should I shoot for the current release (2.4.2),
> which will have those fixed?

I didn't intend to mix those separate issues ;)

Vanilla is better than vendor-patched so that others can quickly
reproduce the same results (IOW roll the next version without
introducing mysterious diffs in the generated files).

If 2.4.2 fixes issues when it is combined with 2.68, go for that.

Re: Version of autoconf for releases?

[Jeff Trawick]

On Tue, Feb 7, 2012 at 4:54 PM, Bojan Smojver  wrote:
> On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
>> Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
>> warnings are coming from (mostly).
>
> Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
> do get warnings and they do come from the files contributed by this
> version of libtool. Pretty much the same stuff as what Rainer fixed in
> APR - missing AC_LANG_SOURCE.
>
> So, given that vanilla autoconf and the one from F-16 are pretty much
> the same thing and given that libtool 2.2.4 is giving warnings (i.e. is
> obviously more obsolete than 2.4, when used with autoconf 2.68), I think
> I should just roll the 1.4.6 release with the tools I have in F-16. If
> that turns out bogus, I will release again. Version numbers are cheap.
>
> If you disagree with this assessment, let me know.

Using the slightly patched tool(s) from Fedora seems like a pain for
others to reproduce exactly, whereas anyone can install autotools of
arbitrary versions on arbitrary non-Windows machines in just a few
minutes.