[PD] Large File Support on Linux

[Miller Puckette]

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