Same problem on RH Enterprise edition ...
yes it doesn't look like platform specific.

Joe Schaefer wrote:
"David Reid" <david@jetnet.co.uk> writes:

[...]

  
Now, can people test them and we'll see if we get enough +1's ?
    

I'm running debian-amd64, however I don't believe the problem
below is platform-specific:

  % cd apr-1.0.rc2; ./configure && make
  ... builds ok ...
  % make check
  (cd test && make check)
  ...
  make[1]: Entering directory `/home/joe/tmp/apr-1.0.rc2/test'
  /bin/sh /home/joe/tmp/apr-1.0.rc2/libtool --silent --mode=compile gcc
  -g -O2 -pthread   -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
  -I../include -I./../include  -o testlock.lo -c testlock.c && touch
  testlock.lo 
  testlock.c:66:22: test_apr.h: No such file or directory


Once again, AFAICT the major version number appearing 
in the .so is not right:

  $ ls .libs
  libapr-1.a   libapr-1.lai  libapr-1.so.0
  libapr-1.la  libapr-1.so   libapr-1.so.0.0.0

If you want the so's major number to be a "1",
by applying the get-version.sh patch I posted 
last week you'll wind up with this:

  % ls .libs
  libapr-1.a   libapr-1.lai  libapr-1.so.1
  libapr-1.la  libapr-1.so   libapr-1.so.1.0.0