Menu
▾
▴
Re: [Mesa3d-users] Visual Studio project files broken?
|
From: Karl S. <kar...@gm...> - 2009-07-27 22:56:08
|
I took a look, and I think that: gl.h has: #if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) #define __WIN32__ #endif and compiler.h has: #if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) && !defined(BUILD_FOR_SNAP) # define __WIN32__ # define finite _finite #endif So if gl.h gets included before compiler.h, finite will not get defined. And that is the real problem. So, probably, between the last two releases, some of the includes got reordered or reorganized and exposed this problem. The "fix" in the patch works because the project files now "force include" compiler.h, which makes the compiler include compiler.h first, before pulling in any other code. I think of this "force include" as a way to work around compiler inconsistencies, and this finite/_finite thing is a good example. Thus, compiler.h is perfect for using with this sort of compiler option. The use of this feature is somewhat debatable. It is sort of robust because if someone uses that macro in a file someplace else that doesn't otherwise include compiler.h, the "forced include" always is in effect. It kind of makes sense to address a compiler/libc weirdness at the source of the weirdness. OTOH, it is sort of an ugly hack and not the sort of thing most people would look for in VisStudio. I'll try to decide what to do before the next release. That will probably involve just removing !defined(__WIN32__) from the check to define _finite. Sort of seems wrong anyway. Thanks, Karl On Mon, Jul 27, 2009 at 3:50 PM, Brian Paul <br...@vm...> wrote: > OK, I committed those files. I didn't see how they fixed the "finite" > problem but I'll take your word for it. :) > > -Brian > > Karl Schultz wrote: > >> Yeah, someone else opened a bug and I put the patch there. >> >> http://bugs.freedesktop.org/show_bug.cgi?id=22882 >> >> On Mon, Jul 27, 2009 at 1:46 PM, Brian Paul <br...@vm... <mailto: >> br...@vm...>> wrote: >> >> >> I don't see how this problem is happening. The files which failed >> to find "finite" (such as s_lines.c) come from use of the >> IS_INF_OR_NAN() macro from imports.h. But imports.h already >> #includes compiler.h >> >> Did either of you have a patch to fix this? >> >> -Brian >> >> Jianrong Shu wrote: >> >> Please go ahead and submit patches as you see fit. >> >> On Tue, Jul 21, 2009 at 12:46 PM, Karl >> Schultz<kar...@gm... >> <mailto:kar...@gm...>> wrote: >> >> Ooops, I didn't see that it got moved to compiler.h. >> >> No, it should not be in two header files; I just didn't see >> that it got >> moved to compiler.h. It should not be in glheader.h. >> >> One correct fix is to add an "#include main/compiler.h" to >> just the files >> that need it. It sort of looks like just a few files were >> missed when the >> macro was moved. Easy to miss these since finite is buried >> inside of other >> macros. >> >> I suppose your solution of forcing the include in all the >> files does the >> same thing and may be less fragile. >> >> Another fix is to add "finite=_finite" to the list of "-D" >> compiler options >> in the mesa and osmesa project files, for all build targets. >> Then, the >> macro definition could be removed from compiler.h. But this >> might force a >> change in the scons build files as well. I don't know, >> because I am not >> familiar with scons. >> >> I'll settle on something and submit patches, unless you'd >> like to do that. >> >> Karl >> >> >> On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu >> <jia...@gm... <mailto:jia...@gm...>> >> wrote: >> >> Thanks. My fix to this was to force including >> 'compiler.h' in the >> project settings. Was there a specific reason that you >> defined the >> same macro in two header files? >> >> Jianrong >> >> On Mon, Jul 20, 2009 at 11:47 PM, Karl >> Schultz<kar...@gm... >> <mailto:kar...@gm...>> >> wrote: >> >> It looks like glheader.h (thankfully) got cleaned up >> quite a bit since >> 7.4. >> In the process, the following was lost: >> >> #if defined(_WIN32) && !defined(__WIN32__) && >> !defined(__CYGWIN__) && >> !defined(BUILD_FOR_SNAP) >> # define __WIN32__ >> # define finite _finite >> #endif >> >> >> Adding back the above will get you going again. >> >> Also, you'll need to: >> >> Add to the mesa project: >> >> cpuinfo.[ch] >> prog_optimize.[ch] >> texgetimage.[ch] >> >> Remove from mesa.def: >> >> _mesa_get_program_register >> >> >> On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu >> <jia...@gm... <mailto:jia...@gm... >> >> >> >> wrote: >> >> I fixed most of the problems except that the >> linker couldn't find the >> definition of _finite function, which is >> Microsoft's implementation of >> isfinite. The error messages as follows: >> >> 1>mesa.lib(s_aatriangle.obj) : error LNK2001: >> unresolved external >> symbol >> _finite >> 1>mesa.lib(s_aaline.obj) : error LNK2001: >> unresolved external symbol >> _finite >> 1>mesa.lib(prog_execute.obj) : error LNK2019: >> unresolved external >> symbol _finite referenced in function >> __mesa_execute_program >> 1>mesa.lib(s_triangle.obj) : error LNK2001: >> unresolved external symbol >> _finite >> 1>mesa.lib(s_lines.obj) : error LNK2001: >> unresolved external symbol >> _finite >> 1>mesa.lib(s_points.obj) : error LNK2001: >> unresolved external symbol >> _finite >> >> This problem might be caused by some settings in >> the project file, but >> I couldn't figure out. Any ideas? >> >> Thanks, >> Jianrong >> >> On Wed, Jun 24, 2009 at 4:24 PM, Brian >> Paul<br...@vm... >> <mailto:br...@vm...>> wrote: >> >> Jianrong Shu wrote: >> >> Hi there, >> >> I tried to build Mesa 7.5 branch on >> Windows using Visual Studio 2008 >> and the VC8 solution file and got >> several errors. >> >> First, the "mesa" project included a >> file "prog_debug.c", which >> doesn't exist. After deleting it from >> the project, I was able to >> compile it successfully. Then, when >> building the "gdi" project, I >> got >> the following error messages: >> >> 1>Linking... >> 1>mesa.def : error LNK2001: unresolved >> external symbol >> _mesa_get_compressed_teximage >> 1>mesa.def : error LNK2001: unresolved >> external symbol >> _mesa_get_program_register >> 1>mesa.def : error LNK2001: unresolved >> external symbol >> _mesa_get_teximage >> 1>mesa.def : error LNK2001: unresolved >> external symbol >> _mglapi_check_multithread >> 1>mesa.def : error LNK2001: unresolved >> external symbol >> _mglapi_get_proc_address >> >> I also tried the master branch and the >> same problem exists. Any fix >> to >> this? >> >> The Visual Studio project files haven't been >> actively maintained >> lately >> (we've been using scons on Windows). >> >> If you can provide updated project files, >> that'd be great. It's just >> a >> matter of removing references to old/removed >> files and adding the new >> ones. >> >> -Brian >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in >> prizes! For a limited >> time, >> vendors submitting new applications to >> BlackBerry App World(TM) will >> have >> the opportunity to enter the BlackBerry >> Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> <mailto:Mes...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> <mailto:Mes...@li...> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> . >> >> >> >> > |
