libgl1 vs C++ transition, round 2

["Marcelo E. Magallon" <mmagallo@debian.org>]

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