[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Mon, 2007-08-13 at 17:58 -0700, Zack Weinberg wrote:
> 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.

I think generally only symbols starting with 'glu[A-Z]' are supposed to
be public.

> 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?

Why don't we ask upstream directly, shall we? :} Adding the mesa3d-dev
list to CC.

Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Reply to: