> Did you really mean to do this?
yes, although I could certainly have done it more neatly. I've
received several requests for this over the last few months and it
seemed to make sense.
> I've cc'd Paul Eggert on this email, the author of
> AC_SYS_LARGEFILE. As far as I know, LFS only matters to programs
> *not* using the 64-bit data types, like off64_t
not quite. You also need open64() and a few others. I handled most of
these previously in rsync but I thought that using getconf would get
things working on a wider range of systems.
I wasn't aware of AC_SYS_LARGEFILE. Can you give me a pointer to it?
> Now, because of the addition above, in 2.4.6 on the same host we have:
> checking for off64_t... no
yep, but as off_t should now be 64 bits it shouldn't matter. Are you
saying that 2.4.6 doesn't give large file support on Solaris 2.7? I
don't have a 2.7 machine so I didn't test on that particular OS (I did
test on Solaris8 though).
> his macro gets it right under HP-UX where `getconf LFS_CFLAGS` does
> not work
sounds good.
> I'm including a patch below to do two things to 2.4.6:
> 1. redirect getconf to 2>/dev/null on systems such as HP-UX where
> % getconf LFS_CFLAGS
> getconf LFS_CFLAGS: Invalid argument
yep, that's worth doing (purely cosmetic of course)
If possible I'd like to delete all the off64_t code in rsync (both in
configure.in and syscall.c) and just use the OS provides mechanisms
for LFS. Essentially rsync has been reproducing the macros that the C
library authors have taken a lot of time to get right which just seems
silly.
