On 8/10/07, Brice Goglin <[EMAIL PROTECTED]> 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, [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?
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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
