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: