Linking to OpenAL dynamically? or, Best sound library?

Started by
5 comments, last by rileyriley 17 years, 10 months ago
I've been doing a little bit of research on sound libraries, and based on what I've seen, I think OpenAL fits my needs the best. It seems relatively small (in terms of executable size) and pretty functional. However, I don't want to link with it statically, because I don't want the trouble that implies with its license (LGPL). Is it easy to link with it dynamically? Or, are there any other libraries that stand out as better than OpenAL, and have LGPL or less restrictive licenses? Thanks for any feedback~ Riley
--Riley
Advertisement

Either SDL_Mixer or FMOD are both great as well.

Depends on your needs, what you're trying to do with your program, etc...

Just my 2 cents.

btw. How could the LGPL be any less restrictive? About the only thing less restrictive than LGPL is the "free-as-in-beer" license.
It's my understanding that under the LGPL, if I use a library and build it into my program (via static linking) I have to supply object files for my entire app so that people could theoretically change the library and then re-link it. That's not the biggest issue ever - I am allowed to supply them at a separate time, so that I don't have to make my download size so much bigger - but it's just kind of a pain.
--Riley
That's now how I read the LGPL at all, a few commerical games use OpenAL and they supply nothing. They also have those expensive lawyers to protect them ;-)

"Those who would give up essential liberty to purchase a little temporary safety deserve neither liberty nor safety." --Benjamin Franklin

Thanks for the feedback. I've included the section of the LGPL that concerns me below~

From http://www.gnu.org/licenses/lgpl.txt:

However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.

[...]

6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.

[...]

Also, you must do one of these things:

a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)

b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.

c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.

d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.

e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.


I don't see how to read that in such a way that I don't have to include (or offer to supply) object files if I link statically. Section b applies if I link dynamically, which is why I want to do it, but I don't really know much about taking a static library and turning into a dynamically linkable one.
--Riley
Why would you want to make a dynamic library out of a static one? The OpenAL sdk includes the dynamic link library already, so you're fine qua LGPL with that.
Another option is audiere, looks nice but haven't really used it myself. It's more of a music library too.
Quote:Original post by DeadXorAlive
The OpenAL sdk includes the dynamic link library already


oh. ::sheepish grin:: When I looked at it I guess I just missed that.

nevermind :o Thanks for the info.

--Riley

This topic is closed to new replies.

Advertisement