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 attachment 98889 [details, diff] 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!
