"Eric G. Miller" wrote:
>
> On Mon, 19 Nov 2001 15:18:42 +0100
> Emil Pedersen <[EMAIL PROTECTED]> wrote:
>
> >
> > Hello everyone.
> >
> > A few days ago I "upgraded" (or tried to) a potato server installation
> > to support files bigger than 2GB.
> > I got the impression that all that was needed was a 2.4.x kernel and
> > the testing/unstable version of libc6/libc6-dev. I did this, used 'dd'
> > to create a 3.5GB large file from /dev/zero and everthing seemed to
> > work.
> >
> > However, today it turns out that the database (Mimer-8.2.2) still does
> > not work the way it's supposed to. It seems like the program is having
> > problem using 'lseek', probably becouse the argument and return-types
> > (off_t) is just 4 bytes long. Indeed when I check the size of 'off_t'
> > ( fprint("Sizeof: %d", sizeof(off_t)); ) it is 4 bytes.
> >
> > The include files indicates that some "kernel/system/..." #define should
> > be set to increase the size, but where do this come from or how is it
> > defined? How do I get the precompiled database to "load" the right
> > (64bit) version of lseek, or in some other way get pass this
> > limitaition.
>
> I think the trick is defining _FILE_OFFSET_BITS = 64.
Yes, I found after sending the letter. But since this only works when
you compile the program yourself, and the database acording to the
support should not suffer from this limit, I thought maybe there was
some magic flip I had to switch. Some key that made lseek syscalls use
the 64-bit version if available or something like that. Perhaps some
missing links from src/include(lib) to kernel-src/include(lib) or some
other issue I'd missed.
I guess I have to talk to the support again, preferably som low-level
supporter.
Thanks for the replies, I appreciate it a lot.
Best regards,
Emil
>
> --
> Eric G. Miller <egm2@jps.net>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
