[Openal-devel] OpenAL & freealut Library Versioning

[Sven Panne]

> -----Original Message-----
> From: openal-devel-admin at opensource.creative.com 
> [mailto:openal-devel-admin at opensource.creative.com] On Behalf 
> Of Ludwig Nussel
> Sent: Montag, 20. Februar 2006 13:59
> To: openal-devel at opensource.creative.com
> Subject: Re: [Openal-devel] OpenAL & freealut Library Versioning
> 
> On Sunday 19 February 2006 16:46, Sven Panne wrote:
> > Should the removal of a purely internal, undocumented global symbol 
> > imply binary incompatibility?
> 
> Is abuse of them common? To actually prevent people from 
> using internal symbols use gcc's visibility attributes or a 
> linker script that makes them local.

Well, I hope abuse is *not* common, but this is of course just guessing.
And we *do* use gcc's visibility attribute if it is supported, but there
are non-gcc systems (hard to believe, but true :-). So I just wanted to
get an impression what side people are on regarding binary
compatibility: The more academical, pure side or the more practical
side.

> > I've just had a look at the Mesa project to see how they 
> handle this 
> > issue, but they do it in a completely strange way IMHO: The 
> resulting 
> > library is libGL.so.1.5.060500, where "1.5" seems to be the OpenGL 
> > spec version which is implemented and "060500" means "Mesa 
> 6.5 patchlevel 0". Hmmm...
> 
> You can name the file as you like. ldconfig creates the 
> libGL.so.1 link for you and applications use libGL.so.1 as 
> the SONAME is libGL.so.1.

But this is exactly wrong IMHO: The "1.5" implies OpenGL 1.5
conformance, and having only the "1" in the SONAME misses some
information. Of course OpenGL spec revisions are always backwards
compatible, but if I write an application explictly using OpenGL 1.5
features, only the "libGL.so.1" dependency is recorded, which is quite
useless. One could use elaborate linker scripts and the like to get more
fine-grained version control (like glibc does it), but doing this
portably is almost impossible. And will Mesa bump the SONAME to
libGL.so.2 when they are OpenGL-2.0-ready?? This whole library
versioning is very confusing and is slowly making me sick... *sigh*

Cheers,
   S.