It seems to me that people who are shipping any deliverables in RPM or other
package systems like Debian's could just have a dependency on the GLU
package being installed. For those shipping tarballs of source/binaries, it
wouldn't be a bad idea to simply point people at a central location for GLU.
As far as I can tell, there is exactly zero reason for anyone to make any
changes to libGLU for any specific driver set, and having it be truly
standard would be ideal for the end user, I believe.
-Nick
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 06, 2000 10:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [oglbase-discuss] Everyone agree that GLU is now a solved
> problem?
>
>
> | 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
>
