Linking against OpenAL on Linux

[chronozphere]

Hey everyone,

OpenAL works fine on windows. Now I want to try it on linux.

Turns out that my the openal.pas unit calls:



LoadLibrary( "libopenal.so" );


While libopenal.so doesn't even exist. However, libopenal.so.1 does exist. ???

What does this mean? I could simply link to "libopenal.so.1" but would this also work on other systems? Can someone explain why the ".1" is there?

Thanks a bunch! :)

[Andru]

Can someone explain why the ".1" is there?
All digits after *.so show full or major version of library. Major - .1, full - .1.12.854(for example in my ArchLinux). libopenal.so and libopenal.so.1 are links to libopenal.so.1.12.854. But libopenal.so doesn't exist in all distributives and it only part of dev-packages(because of using it only for static linking to last version that exist in your system). So you must use LoadLibrary only for libopenal.so.0 and libopenal.so.1. The first one exist only in old distributives(full version was 0.8.xxx), but it API & ABI compatible with new one(OpenAL Soft (http://kcat.strangesoft.net/openal.html)), so you can call LoadLibrary for libopenal.so.1 and if it doesn't exist - try to load libopenal.so.0

Static linking is also a variant, but only for distributives with the same version of OpenAL.

[chronozphere]

Thanks. I'll give that a shot! ;)

[phibermon]

Umm, well I can understand the confusion. I've seen symbolic links from ".so" to things like 'so.1' before now, but then on some libs that doesn't appear to be the case.

Thanks for the explanation Andru, it makes sence that different major revisions would require linking to specific 'so.1' which in turn link to the real version number.

I'd always assumed that these in turn were then linked to '.so' but thinking about it, that doesn't leave enough flexibilty for libs that want/need to change their interface/break compatibility between major revisions.