| Hmmm. You're saying that vendors should never ship GLU? Just
| expect it to be on the customer's machine? For completeness, we (Xi
| Graphics) will always ship GL and GLU with our drivers, since most of the
| GL programs out there also link with GLU.
I think it would be good to get everyone to agree to base their
libGLU on the open source version. There are already several bug
fixes in the open source version. It would also be good to have
installations avoid stomping other versions (nick's suggestion
of not shipping it at all addresses this), but I think this is
going to be messy in the short term. Perhaps we could agree
on having a standard rpm that just contains GLU located somewhere
that anyone can include as part of their set of driver rpms.
|
| The main problem I see with GLU now is that it's C++, so there may
| be mangling issues with the different compilers... Though that's not
| really a GLU-only problem ;-) I believe that Mesa uses a C only version.
| Will Mesa be using the SGI GLU from here on out?
the open source GLU uses C++ internally for the nurbs
implementation, but it does not expose a C++ API so name
mangling is not an issue. The only thing that I am aware is an
issue is that it is a pain to correctly build it under Linux
given the current state of libstdc++, etc. However, this is a
solvable problem.
david
