118600 2006-01-10 17:38 0000 largefile support in audiofile breaks esd on ppc 2007-02-21 04:06:57 0000 1 1 1 Unclassified Gentoo Linux Applications 2005.1 PPC Linux RESOLVED FIXED P2 major --- 1 ed@catmur.co.uk sound@gentoo.org f95.lupo@gmail.com ppc@gentoo.org ed@catmur.co.uk 2006-01-10 17:38:27 0000 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? lu_zero@gentoo.org 2006-01-10 20:53:16 0000 why esd shouldn't use off_t as uint64_t if largefile is set? ed@catmur.co.uk 2006-01-11 03:18:07 0000 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. ed@catmur.co.uk 2006-01-11 03:31:53 0000 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. ed@catmur.co.uk 2006-01-11 04:30:45 0000 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. lu_zero@gentoo.org 2006-01-11 20:37:27 0000 any upstream acknowledge of the issue? ed@catmur.co.uk 2006-01-11 21:05:18 0000 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. flameeyes@gentoo.org 2006-10-04 23:51:29 0000 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. ed@catmur.co.uk 2006-10-05 15:28:42 0000 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. ed@catmur.co.uk 2006-10-05 15:31:02 0000 Created an attachment (id=98889) 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. star@bamba.lt 2006-10-10 16:25:59 0000 Yep it should go upstream. I was running circles around it, until i found the problem. Confirmed on 32-bit ppc. josejx@gentoo.org 2007-02-08 02:20:38 0000 Diego, I can confirm that this fixes the problem on ppc. Would you be okay with applying it? josejx@gentoo.org 2007-02-21 04:06:57 0000 InCVS. Thanks! 98889 2006-10-05 15:31 0000 api_replace_largefile_dependent_types.patch api_replace_largefile_dependent_types.patch text/plain LS0tIGxpYmF1ZGlvZmlsZS9hdWRpb2ZpbGUuaAkyMDA2LzEwLzA1IDIyOjA1OjUwCTEuMQorKysg bGliYXVkaW9maWxlL2F1ZGlvZmlsZS5oCTIwMDYvMTAvMDUgMjI6MDY6MDAKQEAgLTQ1LDggKzQ1 LDggQEAgdHlwZWRlZiBzdHJ1Y3QgX0FGZmlsZXNldHVwICpBRmZpbGVzZXR1cAogdHlwZWRlZiBz dHJ1Y3QgX0FGZmlsZWhhbmRsZSAqQUZmaWxlaGFuZGxlOwogdHlwZWRlZiB2b2lkICgqQUZlcnJm dW5jKShsb25nLCBjb25zdCBjaGFyICopOwogCi10eXBlZGVmIG9mZl90IEFGZnJhbWVjb3VudDsK LXR5cGVkZWYgb2ZmX3QgQUZmaWxlb2Zmc2V0OwordHlwZWRlZiBpbnQ2NF90IEFGZnJhbWVjb3Vu dDsKK3R5cGVkZWYgaW50NjRfdCBBRmZpbGVvZmZzZXQ7CiAKICNkZWZpbmUgQUZfTlVMTF9GSUxF U0VUVVAJKChzdHJ1Y3QgX0FGZmlsZXNldHVwICopIDApCiAjZGVmaW5lIEFGX05VTExfRklMRUhB TkRMRQkoKHN0cnVjdCBfQUZmaWxlaGFuZGxlICopIDApCg==