After investigating bug #783 (Wine20020605: Problems with build of dlls/glu32), here are my conclusions so far (not finished yet, but I need a bit of advice on next direction to pursue):
First, we need to not compile glu32 is no libGLU.so is found. The test for libGLU is already in configure, the only thing missing is some logic in the dlls/Makefile (or maybe dlls/glu32/Makefile?) to not build it.
Next, the version of the GLU implementation of MS is 1.2. That's fine as long as the same (or more recent) version is found while building. I'm currently using Mesa 3.4.2 on RH 7.2, which is GLU 1.1 compliant. The GL/glu.h has the defines for 1.2 and 1.3, but the lib/libGLU.so doesn't have any implementation. Some more recent distributions (eg, RH 7.3) has the SGI GLU implementation which is 1.3. So we need to check this also. What would be the best thing to do if the native GLU is < 1.2? Not build dlls/glu32 at all? There's a way to map 1.1 call to 1.2 or beyond, but not the other way around (or I'm not aware of it).
I finished correcting the prototypes (compliant with MSDN) in glu.c for a native GLU 1.2. Now I'd like to have some input as to what to do wrt a native GLU 1.1.
If you have some advice, I'll appreciate them.
Vincent
On Mon, Jun 10, 2002 at 08:18:38PM -0400, Vincent B?ron wrote:
After investigating bug #783 (Wine20020605: Problems with build of dlls/glu32), here are my conclusions so far (not finished yet, but I need a bit of advice on next direction to pursue):
First, we need to not compile glu32 is no libGLU.so is found. The test for libGLU is already in configure, the only thing missing is some logic in the dlls/Makefile (or maybe dlls/glu32/Makefile?) to not build it.
The code is of course already there for this.
Check dlls/Makefile.in, and mentions of 'GLU32FILES' in configure.ac, which does not recurse into dlls/glu32 if libGLU.so is not there.
So the bug reporter, as you already found, did a 'cd dlls/glu32' and built it himself, which is of course not supported.
Ciao, Marcus