Bug 13544

Summary:	GLU fails compile on Visual Studio 2005 Professional v8.05xxx
Product:	Mesa	Reporter:	daniel chapiesky <dchapiesky>
Component:	GLU	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	major
Priority:	medium	CC:	dchapiesky, t.schmiade
Version:	git
Hardware:	x86 (IA32)
OS:	Windows (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	windows/VC8/mesa solution file with new GLU->GDI depend

Description daniel chapiesky 2007-12-05 21:37:11 UTC

Version of Mesa-7.02 fails to link dll...

simply...

Creating library .\Release/GLU32.lib and object .\Release/GLU32.exp
2>mipmap.obj : error LNK2019: unresolved external symbol _glTexImage3D@40 referenced in function _closestFit3D
2>Release/GLU32.DLL : fatal error LNK1120: 1 unresolved externals

glTexImage is dynamically resolved but vs2005 wants it anyway... I'm looking at it now but if you have already got it...

Comment 1 daniel chapiesky 2007-12-05 21:46:55 UTC

per bug 5661.... on 1/20/200 ===six===


------- Comment #1 From Brian Paul 2006-01-20 07:37:44 PST [reply] ------- 
Fixed in CVS.  Grab the latest s_triangle.c and s_tritemp.h (for the 6.4
branch).
--------------------------------------------------------------------------

The compile works for all except GLU...  still can't link dll..

Comment 2 Timo Schmiade 2008-05-26 03:32:35 UTC

Confirming this bug. Error occurs exactly as described (Windows Vista Home Premium x32) for mesa-7.0.3 when building mipmap.obj.

Suprisingly, when calling the build again, the lib links successfully, making this seem like a project dependency problem.

Comment 3 Brian Paul 2008-05-26 09:34:22 UTC

The glTexImage3D function should be resolved at runtime with wglGetProcAddress().  It looks like the relevant code is surrounded by an #ifdef RESOLVE_3D_TEXTURE_SUPPORT / #endif block.

Can you verify that RESOLVE_3D_TEXTURE_SUPPORT is getting defined (probably in the VS project file)?

Comment 4 Karl Schultz 2008-05-26 20:01:41 UTC

Created attachment 16752 [details]
windows/VC8/mesa solution file with new GLU->GDI depend

Replacement mesa.sln file with added GLU->GDI dependency.  Always build mesa/gdi first.

Comment 5 Karl Schultz 2008-05-26 20:05:55 UTC

Yes, this is a dependency / build-order problem.  If you forcefully build GLU before mesa or gdi, you'll get this problem.  I did too.

If you build the entire solution, it works because the build order was correct.  However, the solution file was missing the explicit GLU->GDI dependency.

I've added it and attached the new mesa.sln file.

It is also simple to work around by not building glu first.

Comment 6 Adam Jackson 2009-08-24 12:28:34 UTC

Mass version move, cvs -> git

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.