Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

audiofile-0.2.6 is built with largefile support.

This breaks on big-endian 32-bit architectures (PPC) because the API and ABI
conflict on the width of off_t; audiofile is built with _FILE_OFFSET_BITS = 64
so its off_t is 64-bit but esd (which links against audiofile) is built without
so its off_t is 32-bit. The result is that functions that return off_t have the
low 32 bits (the ones that matter) discarded. (This is why little-endian 32-bit
architectures (x86) are OK; they discard the high 32 bits of off_t values,
typically all zero.)

Quick fix: build audiofile without largefile on ppc and other big-endian 32-bit
architectures.

Better: make the exposed API of audiofile use a type with well-defined width.
Is this possible?

why esd shouldn't use off_t as uint64_t if largefile is set?

esd is built without largefile support; that's the problem. (Ditto with
anything else built against audiofile and without largefile support.)

Basically, off_t is not suitable for use in API because its width is not well
defined.

Also, there are other packages built against audiofile; these will also break.

Actually, this needs fixing on x86 as well as there are potential crashers in
the API; e.g. afSeekFrame takes an off_t as its last argument (frameoffset); on
x86 only 32 bits will be placed on the stack so the high 32 bits of frameoffset
will be taken from whatever is next on the stack.

Uh, I've found a website that discusses this problem:

http://ac-archive.sourceforge.net/largefile/index.html

It seems changing off_t to int64_t in the exposed audiofile headers will fix
the structure-mismatch and callframe-mismatch problems.

any upstream acknowledge of the issue?

Not much. http://blog.gmane.org/gmane.comp.audio.audiofile (third item)
indicates the audiofile maintainers at least accept the issue exists. Can't
find anything on the Gnome side of things, though. (There is plenty of stuff on
largefile problems, but I can't find any discussions specifically on
audiofile<->esd.)

I imagine relatively few distros compile audiofile with largefile -- Fedora
doesn't, I don't think Debian does; Mandrake does but they don't run on ppc so
they won't have hit this bug.

As upstream seems pretty deadish, would you mind submitting a patch to change
off_t to int64_t ? Or I'll try to do that asap.

Note: test case is:

$ ESDBG=1 esdplay /usr/share/sounds/warning.wav
frames: 0 channels: 1 rate: 44100.000000 format: 401 width: 16

Frames should be 6880 or similar.

I've got a patch; I'm just finishing testing it now. Unfortunately I don't have
access to x86 or amd64 at the moment so someone else will have to test it
there.

Created an attachment (id=98889) [details]
api_replace_largefile_dependent_types.patch

Suggested patch. I think we can get away with something this simple; all that
matters is that int64_t is of constant width and can always store an off_t.

Yep it should go upstream. I was running circles around it, until i found the
problem. Confirmed on 32-bit ppc. 

Diego, I can confirm that this fixes the problem on ppc.  Would you be okay
with applying it?

InCVS.  Thanks!