On Mon, 2002-08-12 at 16:44, Lamar Owen wrote:
> Interesting point. Before I could deploy RPMs with largefile support by
> default, I would have to make sure it wouldn't silently break anything. So
> keep discussing the issues involved, and I'll see what comes of it. I don't
> have an direct experience with the largefile support, and am learning as I go
> with this.
>
> Given that I have to make the source RPM's buildable on distributions that
> might not have the largefile support available, so on those distributions the
> support will have to be unavailable -- and the decision to build it or not to
> build it must be automatable.
I raised the question on the Debian developers' list. As far as I can
see, the general feeling is that it won't break anything but will only
work with kernel 2.4. It may break with 2.0, but 2.0 is no longer
provided with Debian stable, so I don't mind that.
The thread starts at
http://lists.debian.org/debian-devel/2002/debian-devel-200208/msg00597.html
I intend to enable it in the next version of the Debian packages (which
will go into the unstable archive if this works for me) by adding
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 to CFLAGS for the entire build.
One person said:
However compiling with largefile support will change the size
of off_t from 32 bits to 64 bits - if postgres uses off_t or
anything else related to file offsets in a binary struct in one
of the database files you will break stuff pretty heavily. I
would not compile postgres with largefile support until it
is officially supported by the postgres developers.
but I cannot see that off_t is used in such a way.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK
http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"And he spake a parable unto them to this end, that men
ought always to pray, and not to faint."
Luke 18:1
