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, [EMAIL PROTECTED] 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