Re: last days of htdig

[Christopher Faylor <cgf@redhat.com>]

On Sat, Sep 27, 2003 at 03:05:28PM -0700, Ulrich Drepper wrote:
>Christopher Faylor wrote:
>
>>>>I think we've already been over this ground, HP, but couldn't we
>>>>just recompile htdig on the new kernel to bypass the 2G limit?
>>>
>>>Ewwwwww....
>> 
>> ?  I said "kernel" when I really meant glibc but it could have been a
>> real simple way to get things working quickly.
>
>???  glibc doesn't have a 2GB limit.  You have to use the right
>interfaces to get beyond 2GB (e.g. -D_FILE_OFFSET_BITS=64), though.
>Recompiling glibc cannot make this the default.  You'd change the size
>of all kinds of data types after which I doubt you can reboot the system.

cgf said: I think we've already been over this ground, HP, but couldn't we
just recompile htdig on the new kernel to bypass the 2G limit?

then he said: I said "kernel" when I really meant glibc but it could
have been a real simple way to get things working quickly.

Correcting the sentence would give us: I think we've already been over
this ground, HP, but couldn't we just recompile htdig on the new glibc
to bypass the 2G limit?

The "new glibc" in this case would be a glibc (and kernel) from 2003,
when the new sourceware was brought online, rather than one from 1999,
or whenever Jason and company put the old sourceware together.  I wasn't
suggesting that a rebuild of glibc would be necessary.  That would be
counter to my attempts to standardize sourceware so that I can just
run 'up2date' and not worry about anything breaking.

I guess I was assuming that the newer glibc would deal better with
larger file sizes, which may have been an incorrect assumption.  Perhaps
the old glibc worked fine, too.  Regardless, I certainly know that it is
possible to manipulate files over 2GB on linux without rebuilding glibc.

cgf