Hi,
>>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".
>
>
> The library ABI is defined by the project which creates the library, it
> is not OK for package maintainers to go and distribute incompatible
> versions of the library on a whim, especially if they have the same
> soname.
OK, my wrong. I see there's no provision for detecting large file
support in the configure script. I thought there was provision for that.
I guess my question was why large file support was left out of APR in
the first place, not why it was left out of APR RPM packages in the
first place. But then there's probably no reason, other than developers
were not aware/interested...
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 14:17:11 2004