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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list