Re: lseek error / LFS support with potato
Jules Bean wrote:
>
> On Mon, Nov 19, 2001 at 04:44:01PM +0100, Emil Pedersen wrote:
> >
> > 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.
>
> But that couldn't possibly work.
>
> The program is compiled. It has compiled into it code which knows
> that off_t is 4 bytes long. E.g. it only allocates 4 byts on the
> stack for off_t, that sort of thing. It couldn't possibly work with
> an 8 byte off_t.
>
> Change the size of a data type, in a language like C, will always
> force a recompile...
Your right, and I normally knows that. I guess I got confused by,
---from http://www.suse.de/~aj/linux_lfs.html----
Programs compiled against glibc 2.1.3 will work on LFS system,
there's no need to recompile the programs (with the exception of
the 64 bit fcntl locking). Only glibc needs to be updated to support
LFS.
-------
and thought that it included the actual _use_ of files +2G. (What it
really says is that the old syscalls still work with the same
limitations, right?)
Anyway, the company that made the program later admitted that it didn't
work with files larger than 2G. If they had done this earlier it would
have saved me some confusion and a lot of stress:-)
Regards,
Emil
>
> Jules
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: