Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


How to statically link OpenAL-Soft for VC++


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 Petwoip   Members   -  Reputation: 128

Like
0Likes
Like

Posted 29 March 2013 - 06:51 PM

I've been looking all over the internet for a guide to link OpenAL-Soft statically with VC++. At the moment I have it working dynamically, but all my other libraries are statically linked and it would be really nice if I could do the same with OpenAL-Soft. I keep hearing that static linking is discouraged for OpenAL-Soft due to licensing issues, but according to this post, I should be fine.

 

I was able to compile the library statically by doing "cmake -DLIBTYPE=STATIC .." and moving the generated lib file to my game's folder, but when building my program I got unresolved external symbol errors when calling OpenAL functions. I made sure that the lib was included in the VS linker settings. Not sure what to try at this point.

 

Thanks!


Edited by Petwoip, 29 March 2013 - 06:58 PM.


Sponsor:

#2 Gambini   Members   -  Reputation: 384

Like
0Likes
Like

Posted 30 March 2013 - 02:50 PM

May I suggest that you don't? I'll give an example specifically for openal-soft:

 

I tried to run Euro Truck Simulator 2, but it would crash immediately on startup. I remembered that this happened for one specific version of openal soft when working on my own game, so I was able to replace ETS2's dll with a newer one, which stopped the crashing. It took a few hours of reinstalling and trying everything under the sun before I realized it, but I would not have been able to play if they had linked it statically.

 

 

That said...

Compiling (which you said you did, and cmake probably did the right thing):

Go to openAL-soft's config.h (should be in the directory where the other openal projects are generated), and make AL_API and ALC_API defined as nothing. Then, go in to the OpenAL32 project in VS -> Properties -> General -> Configuration Type set to static library. Of course, do this for all release/debug/whatever else. Build OpenAL like that.

 

Linking:

In the project that you intend to statically link openAL in to, have AL_LIBTYPE_STATIC defined (Project-> Properties-> C/C++ ->Preprocessor -> Preprocessor Definitions). Found that in al.h line 9.



#3 Petwoip   Members   -  Reputation: 128

Like
0Likes
Like

Posted 31 March 2013 - 01:56 PM

Thanks for the help Gambini, that works!



#4 Martins Mozeiko   Crossbones+   -  Reputation: 1422

Like
2Likes
Like

Posted 31 March 2013 - 02:17 PM

but according to this post, I should be fine.

The information in link is a bit incorrect.

 

LGPL requires (from http://www.gnu.org/copyleft/lesser.html):

d) Do one of the following:

  • 0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
  • 1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

So you are required to provide sources of your app, so users can link to different implementation of OpenAL library. Or you are required to use shared library when linking to OpenAL.



#5 Petwoip   Members   -  Reputation: 128

Like
0Likes
Like

Posted 01 April 2013 - 02:49 AM

Hmm, I should have investigated further... I guess I'll stick with using a shared library because I might want to keep my app closed source.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS