[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] [perl bindings] Bizarre copy of UNKNOWN in subroutine

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 11 Jul 2011 13:51:45 +0100

Stéphane Gaudreault <stephane_at_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
Received on 2011-07-11 14:52:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.