Bug#319388: [libglu1-xorg] should hide C++ interfaces

["Zack Weinberg" <zackw@panix.com>]

On 8/10/07, Brice Goglin <Brice.Goglin@ens-lyon.org> wrote:
> >> If you are still interested in fixing this problem, I would appreciate
> >> if you could send an updated patch. But please do not prepare it against
> >> Mesa 6.5.1 in Etch (such a change won't be accepted in Etch anyway). You
> >> should prepare it against Mesa 6.5.2-3 in experimental (where the Mesa
> >> packaging has been getting a large rework).
>
> Any news about this?

I'm sorry, I clean forgot about it. :-/

I have looked at the mesa 7.0.1-1 packages that just hit unstable.
The good news is, it looks a *lot* easier to do a patch that will
integrate nicely with upstream.  The bad news is, I need help with a
few things before I can do it.

First and most important: I need to know exactly which symbols are
part of the public interface of libGLU.so.1.  In my old patch I
guessed based on the contents of the Windows DLL definition file, but
looking more closely I don't think that's correct.  libGLU.so.1
exports a lot of symbols that are neither C++ mangled names (and
therefore private by assumption) nor listed in that file.  If I
further assume that any name starting with an underscore is private, I
get this list of symbols that might plausibly be public:

        area
        bezierPatchDelete
        bezierPatchDeleteList
        bezierPatchDraw
        bezierPatchEval
        bezierPatchEvalNormal
        bezierPatchInsert
        bezierPatchListDraw
        bezierPatchMake
        bezierPatchMake2
        bezierPatchMeshBeginStrip
        bezierPatchMeshDelDeg
        bezierPatchMeshDelete
        bezierPatchMeshDraw
        bezierPatchMeshEndStrip
        bezierPatchMeshEval
        bezierPatchMeshInsertUV
        bezierPatchMeshListCollect
        bezierPatchMeshListDelDeg
        bezierPatchMeshListDelete
        bezierPatchMeshListDraw
        bezierPatchMeshListEval
        bezierPatchMeshListInsert
        bezierPatchMeshListNumTriangles
        bezierPatchMeshListPrint
        bezierPatchMeshListReverse
        bezierPatchMeshListTotalStrips
        bezierPatchMeshListTotalVert
        bezierPatchMeshMake
        bezierPatchMeshMake2
        bezierPatchMeshNumTriangles
        bezierPatchMeshPrint
        bezierPatchMeshPutPatch
        bezierPatchPrint
        bezierPatchPrintList
        drawStrips
        gluDeleteNurbsTessellatorEXT
        glu_LOD_eval_list
        pointLeft2Lines
        pointLeftLine

I'm guessing that some, but not all, of these are public.  (For
instance, I'm pretty sure "area" isn't. ;-)  Could you check with
someone who knows from GLU?  If you do, please also check that all the
underscore-prefixed symbols (mostly __gl_thingy) are meant to be
private.

Second, the bin/mklib script has some internal support for restricting
the set of exports (the -exports option) but that feature has a
critical bug when used with Linux/Solaris version scripts: it assigns
all symbols the same version, derived from the soname.  This is wrong.
 Symbol versions are part of the ABI and need to stay stable once
assigned; if a program that wants, say, gluNewQuadric@GLU_1.0 is run
with a libglu.so that only has a @GLU_1.1 version, the dynamic linker
will barf.

My preferred way to deal with this would be to have a GNU-ld-style
version script for GLU in the source tree, and document that mklib
-exports expects a file in that format.  mklib would then convert that
to whatever format other platforms' linkers want -- as far as I know,
the GNU version script is strictly more featureful than any other
similar format. I'm not going to implement the conversions, though;
that's for the maintainers of the support for those other platforms.
Do you think that would be something you could get back into upstream?

Third - The Debian diff for mesa-7.0.1-1 looks very strange.  There
are a whole lot of files being created by it, outside of debian/,
including enormous blocks of what looks like upstream source code.
There's *also* a debian/patches directory, and logic in debian/rules
to use it.  As a result I don't know how you want me to generate the
patch.  Could you explain a litle about how the packaging is being
done?

Thanks,
zw