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

Re: svnadmin hotcopy failing

From: Dimitri Papadopoulos-Orfanos <papadopo_at_shfj.cea.fr>
Date: 2004-05-13 12:04:20 CEST

Hi,

> With what "fix"? Using -D_FILE_OFFET_BITS=64? This creates APR
> libraries with a non-default ABI but the default soname. That is a
> shooting offence for a package maintainer.

I see. From what I can understand, APR is using off_t (or a typedef of
it) in its API (that is, in a public header file as opposed to a source
file). In which case switching from a 32-bit to a 64-bit off_t would
indeed break binary compatibility.

If so, it's too late to change anything now, but I wonder why APR RPM
packages wwere built with a 32-bit off_t in the first place. On Linux
most software is built with _FILE_OFFSET_BITS=64 defined these days.
This is not a "fix".

> I said it last week, and I'll say it this week, and it'll still be true
> next week too :) APR 0.9 does not support >2gb files on platforms with a
> 32-bit off_t.

OK, but with _FILE_OFFSET_BITS=64 or a similar macro defined, all recent
Unix and Linux platforms actually have a 64-bit off_t. And most software
is compiled with _FILE_OFFSET_BITS=64 defined these days. Linux and Unix
platforms are not really platforms with a 32-bit off_t.

If I understand correctly, APR could actually support large files, but
enabling large file support would break binary compatibility in APR, so
it's kept disabled for now, probably until the next major version number
leap.

Dimitri

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 13 12:04:59 2004

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

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