On further thought, I don't think it's even possible to change open_via_path() to use open64() and maintain even source compatibility for externs - if one of them calls lseek or fstat we're sunk - and I don't see any robust way of aliasing those calls to lseek64() etc.
I'm now realizing too that I don't know what approaches the Mac and Microsoft pltforms are taking to large file support - I think any solution will have to somehow address all of the platforms.
For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do that internally to d_soundfile.c so as to cause the least possible disruption in a 'bugfix' pd release (probably 0.44-3).
cheers Miller On Tue, Mar 19, 2013 at 08:55:07PM +0100, Charles Goyard wrote:
Hi,
I am in favour of breaking binary compatibility and keeping the code simple. People that compile their externals themselves can understand and cope with it. Other people mostly won't notice.
My intuition is that if the LFS project was unable to provide a transparent API in the first place, there's no reason we will be able to do anything clean.
Just communicate enough about the breakage and enjoy :).
Miller Puckette wrote:
To answer Ico's question, the trouble I forsee is musician A gives musician B a patch, containing compiled externs - and then musician B runs it and gets a crash instead of music. Sub-optimal in my opinion :)
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list