Fwd: Re: [Openal] alutLoadWAVFile

[Panne Sven Com MD PBM IPM TPS 4]

My question was more geared towards the problem that both AL/ALC and ALUT
have been shipped as a *single* library on Linux. This is highly undesirable
if ALUT is a more independent project with independent release cycles etc.,
but on the other hand we might want to have some binary compatibility for
already existing apps.

IMHO the best way to proceed here would be to make a clean cut and throw
ALUT stuff out of libopenal.so and have a separate libalut.so. To ease the
transition, binary releases for AL/ALC could include an additional
"combined" libopenal.so, so desparate people could still use old apps using
ALUT via libopenal.so through some LD_LIBRARY_PATH/symbolic link fiddling.

Cheers,
   S.

> -----Original Message-----
> From: openal-admin at opensource.creative.com 
> [mailto:openal-admin at opensource.creative.com] On Behalf Of 
> Ryan C. Gordon
> Sent: Montag, 22. August 2005 13:11
> To: openal at opensource.creative.com
> Subject: Re: Fwd: Re: [Openal] alutLoadWAVFile
> 
> 
> > The most critical issue I see is the "How to ship ALUT?" 
> question, for 
> > which Steve already made a proposal in his last mail, which 
> would be 
> > OK for me, but what about the other people on this list?
> 
> LGPL or more free is probably fine for anything that is meant 
> to be used with an LGPL'd OpenAL; the problem right now is 
> that it can't be statically linked if it's LGPL'd, but if 
> it's designed correctly, it doesn't need to be.