libgl1 vs C++ transition, round 2
Hi,
Recap:
* libgl1 is a pure virtual package which should provide:
+ libGL.so.1, a library implementing the OpenGL 1.x C API
+ libGLU.so.1, a library implementing the GL Utility library
API
* By "implementing the ... C API" I mean the library exports the
symbols corresponding to the C functions declared in the
corresponding header files. Read further if you don't understand
why it is necessary to make this difference/annotation.
* All the implementations of libGL.so.1 that we ship are written in
C
* Some implementations of libGLU.so.1 are written in C, and others
are written in C++; the ones in sid are all written in C++. The
calling conventions are all C. The C++ implementations don't
export functions with C++ calling conventions. The current
versions written in C++ link against:
libstdc++.so.5
libm.so.6
libc.so.6
libgcc_s.so.1
As I understand the situation, the need for a transition comes from the
fact that the mangling of symbols is different across different
releases of the g++ compiler. That means you have libfoo.so.1
exporting different symbols depending on which compiler was used,
effectively creating two different versions of the library which happen
to have the same soname. We are just hacking our way arround the
problem by ensuring that it's not possible to install a package with a
mixed set of libraries.
In particular, it is _not_ a problem if a program ends up linking
against two different libstdc++ libraries, right? It's inefficient,
but otherwise irrelevant. I just want to make sure before I remove the
otherwise misleading "c102" bit from the libglu1c102 package.
Thanks,
Marcelo
Reply to: