You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stéphane Gaudreault <st...@archlinux.org> on 2011/07/04 12:58:47 UTC
[PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Here is a patch that fix compilation of the perl bindings on i686 :
https://bugs.archlinux.org/task/24540
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628507
This problem was also discussed on the user mailing list.
Regards,
--
Stéphane Gaudreault
ArchLinux developer
=====================================
diff -Naur subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in
--- subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in 2010-11-24 20:42:16.000000000 +0000
+++ subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in 2011-07-01 20:16:16.520892074 +0000
@@ -43,7 +43,7 @@
my %config = (
ABSTRACT => 'Perl bindings for Subversion',
DEFINE => $cppflags,
- CCFLAGS => $cflags,
+ CCFLAGS => $Config{ccflags},
INC => join(' ',$apr_cflags, $apu_cflags,
" -I$swig_srcdir/perl/libsvn_swig_perl",
" -I$svnlib_srcdir/include",
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 7 juillet 2011 09:38:08, Philip Martin a écrit :
> Stéphane Gaudreault <st...@archlinux.org> writes:
> > Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
> >> If you change the line in configure from
> >>
> >> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e
> >>
> >> ccopts`"
> >>
> >> to
> >>
> >> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `unset CFLAGS; $PERL
> >>
> >> -MExtUtils::Embed -e ccopts`"
> >>
> >> does it fix the problem?
> >
> > make test still fails with the "Bizarre copy of UNKNOWN" error when I
> > change this line in configure.
>
> So what is SWIG_PL_INCLUDES in your Makefile?
In the toplevel Makefile :
original :
SWIG_PL_INCLUDES = $(SWIG_INCLUDES) -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -
I/usr/lib/perl5/core_perl/CORE
with the change in the SWIG_PL_INCLUDES line in configure
SWIG_PL_INCLUDES = $(SWIG_INCLUDES) -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -
I/usr/lib/perl5/core_perl/CORE
They are identical.
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
> Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
>> If you change the line in configure from
>>
>> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e
>> ccopts`"
>>
>> to
>>
>> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `unset CFLAGS; $PERL
>> -MExtUtils::Embed -e ccopts`"
>>
>> does it fix the problem?
>
> make test still fails with the "Bizarre copy of UNKNOWN" error when I change this line in configure.
>
So what is SWIG_PL_INCLUDES in your Makefile?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 7 juillet 2011 08:43:06, Philip Martin a écrit :
> Stéphane Gaudreault <st...@archlinux.org> writes:
> > # perl -MExtUtils::Embed -e ccopts
> >
> > -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
> > -I/usr/local/include -D_LARGEFILE_SOURCE -
> >
> > D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/core_perl/CORE
> >
> > It seems that the new perl 5.14 ExtUtils::MakeMaker it doesn't work well
> > on i686 [1]. Maybe these two issues are be related ?
> >
> > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628522
>
> If you change the line in configure from
>
> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e
> ccopts`"
>
> to
>
> SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `unset CFLAGS; $PERL
> -MExtUtils::Embed -e ccopts`"
>
> does it fix the problem?
make test still fails with the "Bizarre copy of UNKNOWN" error when I change this line in configure.
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
> # perl -MExtUtils::Embed -e ccopts
> -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -
> D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/core_perl/CORE
>
> It seems that the new perl 5.14 ExtUtils::MakeMaker it doesn't work well on i686 [1]. Maybe these two issues are be related ?
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628522
If you change the line in configure from
SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `$PERL -MExtUtils::Embed -e ccopts`"
to
SWIG_PL_INCLUDES="\$(SWIG_INCLUDES) `unset CFLAGS; $PERL -MExtUtils::Embed -e ccopts`"
does it fix the problem?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 7 juillet 2011 07:27:05, Philip Martin a écrit :
> Stéphane Gaudreault <st...@archlinux.org> writes:
> >> What is the typdef line for apr_off_t in apr.h? It should be something
> >> that is 64bit irrespective of _FILE_OFFSET_BITS.
> >
> > typedef off64_t apr_off_t;
>
> So APR/Subversion are using 64-offsets irrespective of
> _FILE_OFFSET_BITS.
>
> >> Are there any occurences of plain off_t in the Swig generated code?
> >>
> >> grep '[^_]off_t' subversion/bindings/swig/perl/native/*c
> >
> > No.
>
> There must be some code somewhere that does depend on _FILE_OFFSET_BITS.
>
> From another 32-bit machine it appears that -D_FILE_OFFSET_BITS=64
> usually appears in SWIG_PL_INCLUDES in the top level Makefile. It gets
> there via:
>
> perl -MExtUtils::Embed -e ccopts
>
> What does that return on your machine?
# perl -MExtUtils::Embed -e ccopts
-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I/usr/lib/perl5/core_perl/CORE
It seems that the new perl 5.14 ExtUtils::MakeMaker it doesn't work well on i686 [1]. Maybe these two issues are be related ?
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628522
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
>> What is the typdef line for apr_off_t in apr.h? It should be something
>> that is 64bit irrespective of _FILE_OFFSET_BITS.
>
> typedef off64_t apr_off_t;
So APR/Subversion are using 64-offsets irrespective of
_FILE_OFFSET_BITS.
>> Are there any occurences of plain off_t in the Swig generated code?
>>
>> grep '[^_]off_t' subversion/bindings/swig/perl/native/*c
>
> No.
There must be some code somewhere that does depend on _FILE_OFFSET_BITS.
>From another 32-bit machine it appears that -D_FILE_OFFSET_BITS=64
usually appears in SWIG_PL_INCLUDES in the top level Makefile. It gets
there via:
perl -MExtUtils::Embed -e ccopts
What does that return on your machine?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 6 juillet 2011 05:42:15, Philip Martin a écrit :
> Stéphane Gaudreault <st...@archlinux.org> writes:
> > # apr-1-config --cflags
> >
> > -pthread
> >
> > # apr-1-config --cppflags
> >
> > -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
>
> So that is the standard APR with large-file support. APR doesn't use
> -D_FILE_OFFSET_BITS=64 because it defines its own 64bit apr_off_t and
> uses that. Subversion follows APR and also uses apr_off_t. The Swig
> generated code should only depend on APR/Subversion types.
>
> I don't know what has gone wrong.
>
> What is the typdef line for apr_off_t in apr.h? It should be something
> that is 64bit irrespective of _FILE_OFFSET_BITS.
typedef off64_t apr_off_t;
> Are there any occurences of plain off_t in the Swig generated code?
>
> grep '[^_]off_t' subversion/bindings/swig/perl/native/*c
No.
apr version 1.4.5, apr-util version 1.3.12.
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
> # apr-1-config --cflags
> -pthread
>
> # apr-1-config --cppflags
> -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
So that is the standard APR with large-file support. APR doesn't use
-D_FILE_OFFSET_BITS=64 because it defines its own 64bit apr_off_t and
uses that. Subversion follows APR and also uses apr_off_t. The Swig
generated code should only depend on APR/Subversion types.
I don't know what has gone wrong.
What is the typdef line for apr_off_t in apr.h? It should be something
that is 64bit irrespective of _FILE_OFFSET_BITS.
Are there any occurences of plain off_t in the Swig generated code?
grep '[^_]off_t' subversion/bindings/swig/perl/native/*c
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 5 juillet 2011 15:51:58, Philip Martin a écrit :
> Stefan Sperling <st...@elego.de> writes:
> > This pretty much confirms the suspicion that this is a packaging
> > problem, as discussed here:
> > http://svn.haxx.se/users/archive-2011-06/0261.shtml
> >
> > Please fix the packaging of Perl and Subversion in Arch Linux.
> > Other affected distributions should do the same.
>
> Subversion gets large-file support from APR, so I suspect APR has been
> built without large-file support. What do you get for:
>
> apr-config --cflags
> apr-config --cppflags
# apr-1-config --cflags
-pthread
# apr-1-config --cppflags
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stefan Sperling <st...@elego.de> writes:
> This pretty much confirms the suspicion that this is a packaging
> problem, as discussed here:
> http://svn.haxx.se/users/archive-2011-06/0261.shtml
>
> Please fix the packaging of Perl and Subversion in Arch Linux.
> Other affected distributions should do the same.
Subversion gets large-file support from APR, so I suspect APR has been
built without large-file support. What do you get for:
apr-config --cflags
apr-config --cppflags
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Jul 05, 2011 at 03:27:51PM -0400, Stéphane Gaudreault wrote:
> Compilation is not failing. The bindings fail at runtime on i686, but works on
> x86_64.
>
> Here are the perl and subversion cflags on i686 :
>
> subversion: -march=i686 -mtune=generic -O2 -pipe -pthread -
> D_LARGEFILE64_SOURCE -DNE_LFS
>
> perl: -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
> -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> I think the problem may be caused by the absence of -D_FILE_OFFSET_BITS=64 in
> the subversion cflags. I do not get the failure in the "make test" if I do
> export CFLAGS+=" -D_FILE_OFFSET_BITS=64"
> before building subversion.
>
Hi Stéphane,
This pretty much confirms the suspicion that this is a packaging
problem, as discussed here:
http://svn.haxx.se/users/archive-2011-06/0261.shtml
Please fix the packaging of Perl and Subversion in Arch Linux.
Other affected distributions should do the same.
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 11 juillet 2011 16:20:38 Philip Martin a écrit :
> Philip Martin <ph...@wandisco.com> writes:
> > However this object code is dynamically loaded by Perl at runtime so
> > it's not impossible that the Perl compiler flags need to be applied. It
> > seems to me that Subversion is responsible for ensuring that this is
> > done and that we should be fixing this in Subversion.
>
> I propose to compile with both Subversion and Perl flags using the
> following patch:
The patch works for me.
Stéphane
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Jul 11, 2011 at 04:20:38PM +0100, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
>
> > However this object code is dynamically loaded by Perl at runtime so
> > it's not impossible that the Perl compiler flags need to be applied. It
> > seems to me that Subversion is responsible for ensuring that this is
> > done and that we should be fixing this in Subversion.
>
> I propose to compile with both Subversion and Perl flags using the
> following patch:
Fine with me if this helps.
This won't prevent problems if flags used by Perl override flags used
by Subversion in some bad way. But I have no better idea to offer either.
> Index: subversion/bindings/swig/perl/native/Makefile.PL.in
> ===================================================================
> --- subversion/bindings/swig/perl/native/Makefile.PL.in (revision 1145056)
> +++ subversion/bindings/swig/perl/native/Makefile.PL.in (working copy)
> @@ -60,7 +60,7 @@
> my %config = (
> ABSTRACT => 'Perl bindings for Subversion',
> DEFINE => $cppflags,
> - CCFLAGS => $cflags,
> + CCFLAGS => join(' ', $cflags, $Config{ccflags}),
> INC => join(' ',$apr_cflags, $apu_cflags,
> " -I$swig_srcdir/perl/libsvn_swig_perl",
> " -I$svnlib_srcdir/include",
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> However this object code is dynamically loaded by Perl at runtime so
> it's not impossible that the Perl compiler flags need to be applied. It
> seems to me that Subversion is responsible for ensuring that this is
> done and that we should be fixing this in Subversion.
I propose to compile with both Subversion and Perl flags using the
following patch:
Index: subversion/bindings/swig/perl/native/Makefile.PL.in
===================================================================
--- subversion/bindings/swig/perl/native/Makefile.PL.in (revision 1145056)
+++ subversion/bindings/swig/perl/native/Makefile.PL.in (working copy)
@@ -60,7 +60,7 @@
my %config = (
ABSTRACT => 'Perl bindings for Subversion',
DEFINE => $cppflags,
- CCFLAGS => $cflags,
+ CCFLAGS => join(' ', $cflags, $Config{ccflags}),
INC => join(' ',$apr_cflags, $apu_cflags,
" -I$swig_srcdir/perl/libsvn_swig_perl",
" -I$svnlib_srcdir/include",
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
> I think the problem may be caused by the absence of -D_FILE_OFFSET_BITS=64 in
> the subversion cflags. I do not get the failure in the "make test" if I do
> export CFLAGS+=" -D_FILE_OFFSET_BITS=64"
> before building subversion.
I don't know whether we can dismiss this as a packaging bug, or whether
it is a bug in Subversion.
On 32-bit systems APR builds large-file support (LFS) without using
-D_FILE_OFFSET_BITS=64 by defining its own 64-bit type for apr_off_t.
Subversion gets LFS from APR and so does the same.
The code in subversion/bindings/swig/perl/native is generated by SWIG
and targeted at Perl. The parts generated from Subversion code should
be independent of _FILE_OFFSET_BITS but that may not apply to an any
glue code added by SWIG.
The tests do pass on another 32-bit Linux systems, but that doesn't use
Perl 5.14. I don't know which bit of the glue code would matter, or why
the problem appears to affect just recent Perl 5.14. I suppose adding
-save-temps to CFLAGS and then comparing two .i files from different
builds, with/without -D_FILE_OFFSET_BITS=64, might pinpoint the code
that changes.
However this object code is dynamically loaded by Perl at runtime so
it's not impossible that the Perl compiler flags need to be applied. It
seems to me that Subversion is responsible for ensuring that this is
done and that we should be fixing this in Subversion.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Stéphane Gaudreault <st...@archlinux.org>.
Le 5 juillet 2011 04:24:11, Philip Martin a écrit :
> Stéphane Gaudreault <st...@archlinux.org> writes:
> > Here is a patch that fix compilation of the perl bindings on i686 :
> Is the compilation failing? I think the compilation works, the problem
> is the bindings fail at runtime.
>
> > https://bugs.archlinux.org/task/24540
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628507
> >
> > This problem was also discussed on the user mailing list.
> >
> > diff -Naur
> > subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.i
> > n subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in
> > ---
> > subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.i
> > n 2010-11-24 20:42:16.000000000 +0000 +++
> > subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in 20
> > 11-07-01 20:16:16.520892074 +0000 @@ -43,7 +43,7 @@
> >
> > my %config = (
> >
> > ABSTRACT => 'Perl bindings for Subversion',
> > DEFINE => $cppflags,
> >
> > - CCFLAGS => $cflags,
> > + CCFLAGS => $Config{ccflags},
> >
> > INC => join(' ',$apr_cflags, $apu_cflags,
> >
> > " -I$swig_srcdir/perl/libsvn_swig_perl",
> > " -I$svnlib_srcdir/include",
>
> The problem appears to be that Subversion's Perl extension and Perl
> itself are compiled using incompatible compiler flags, and this causes a
> problem at runtime. Let's see if we can confirm that first. What are
> the values of $cflags and $Config{ccflags)? Add something like:
>
> print "subversion: $cflags \n";
> print "perl: $Config{ccflags} \n";
>
> to Makefile.PL and run 'make swig-pl'.
>
> Your solution is to compile the extension using Perl's compiler flags
> rather than Subversion's flags. That will fix any incompatibility
> between Perl and the extension. What worries me is that it may just
> move the problem to boundary with Subversion itself. The C code in
> subversion/bindings/swig/perl/native will be compiled with the Perl
> compiler flags and so any incompatibility is still present in the calls
> into the Subversion libraries.
>
> It might be better to rebuild Subversion using flags that are compatible
> with Perl.
Compilation is not failing. The bindings fail at runtime on i686, but works on
x86_64.
Here are the perl and subversion cflags on i686 :
subversion: -march=i686 -mtune=generic -O2 -pipe -pthread -
D_LARGEFILE64_SOURCE -DNE_LFS
perl: -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
I think the problem may be caused by the absence of -D_FILE_OFFSET_BITS=64 in
the subversion cflags. I do not get the failure in the "make test" if I do
export CFLAGS+=" -D_FILE_OFFSET_BITS=64"
before building subversion.
Regards,
Stéphane
Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine
Posted by Philip Martin <ph...@wandisco.com>.
Stéphane Gaudreault <st...@archlinux.org> writes:
> Here is a patch that fix compilation of the perl bindings on i686 :
Is the compilation failing? I think the compilation works, the problem
is the bindings fail at runtime.
> https://bugs.archlinux.org/task/24540
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628507
>
> This problem was also discussed on the user mailing list.
>
> diff -Naur subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in
> --- subversion-1.6.17.ori/subversion/bindings/swig/perl/native/Makefile.PL.in 2010-11-24 20:42:16.000000000 +0000
> +++ subversion-1.6.17/subversion/bindings/swig/perl/native/Makefile.PL.in 2011-07-01 20:16:16.520892074 +0000
> @@ -43,7 +43,7 @@
> my %config = (
> ABSTRACT => 'Perl bindings for Subversion',
> DEFINE => $cppflags,
> - CCFLAGS => $cflags,
> + CCFLAGS => $Config{ccflags},
> INC => join(' ',$apr_cflags, $apu_cflags,
> " -I$swig_srcdir/perl/libsvn_swig_perl",
> " -I$svnlib_srcdir/include",
>
The problem appears to be that Subversion's Perl extension and Perl
itself are compiled using incompatible compiler flags, and this causes a
problem at runtime. Let's see if we can confirm that first. What are
the values of $cflags and $Config{ccflags)? Add something like:
print "subversion: $cflags \n";
print "perl: $Config{ccflags} \n";
to Makefile.PL and run 'make swig-pl'.
Your solution is to compile the extension using Perl's compiler flags
rather than Subversion's flags. That will fix any incompatibility
between Perl and the extension. What worries me is that it may just
move the problem to boundary with Subversion itself. The C code in
subversion/bindings/swig/perl/native will be compiled with the Perl
compiler flags and so any incompatibility is still present in the calls
into the Subversion libraries.
It might be better to rebuild Subversion using flags that are compatible
with Perl.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com