apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amit Athavale <amit_athav...@persistent.co.in>
Subject Re: 1.0 rc2 Tarballs
Date Wed, 30 Jun 2004 14:54:31 GMT
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
>
>  
>


Mime
View raw message