[lkml]   [2000]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: is LFS broken in 2.4.0-test5?
In <Pine.LNX.4.21.0007301654330.2671-100000@saturn.homenet> Tigran Aivazian ( wrote:
> Hi guys,

> # lame -h -r isaiah.cdda.raw isaiah.mp3
> Could not find "isaiah.cdda.raw".
> # ls -l isaiah.cdda.raw
> -rw-r--r-- 1 root root 2253843984 Jul 30 16:33 isaiah.cdda.raw
> # ls -lh isaiah.cdda.raw
> -rw-r--r-- 1 root root 2.1G Jul 30 16:33 isaiah.cdda.raw
> #
> #
> # truss lame -h -r isaiah.cdda.raw isaiah.mp3 2>&1 | grep open
> [skipping irrelevant lines]
> open("isaiah.cdda.raw", O_RDONLY) = -1 EFBIG (File too large)
open(2), not open64(2) ! This is correct behaviour.

> # uname -a
> Linux saturn 2.4.0-test5 #1 SMP Fri Jul 28 10:39:22 BST 2000 i686 unknown

> It makes sense for this to happen if the lame(1) was compiled without
> appropriate file_offset_bits (sp) defined but, nevertheless, I remember
> than in ac kernels this worked anyway (not 100% sure, but at the time when
> I used ac kernels I ripped Genesis and Psalms from cdda->mp3 and they
> must have been more than 2G surely...)

If they worked it was bug.

> Obviously, this is very much mission-critical for me (I don't want
> separate "tracks"!) - I guess I will fiddle with lame(1) source to see if
> I need some -D somewhere but first I will recheck if AC kernels worked.

You need only one define: -D_FILE_OFFSET_BITS=64. It'll force GlibC to
use alias open64 to open (and off_t will be 8 bytes long, of course).
90% (if not 99%) of programs will work just fine with this define but
there are few who do not (RPM 3.x, for example: RPM playing durty tricks
with libio and failes miserable with such define).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.039 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site