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:
> 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
I think generally only symbols starting with 'glu[A-Z]' are supposed to
> 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