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 <brianp@vmware.com> 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 <brianp@vmware.com <mailto:brianp@vmware.com>> 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<karl.w.schultz@gmail.com
       <mailto:karl.w.schultz@gmail.com>> 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
           <jianrong.shu@gmail.com <mailto:jianrong.shu@gmail.com>>

           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<karl.w.schultz@gmail.com
               <mailto:karl.w.schultz@gmail.com>>

               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
                   <jianrong.shu@gmail.com <mailto:jianrong.shu@gmail.com>>

                   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<brianp@vmware.com
                       <mailto:brianp@vmware.com>> 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
                       Mesa3d-users@lists.sourceforge.net
                       <mailto:Mesa3d-users@lists.sourceforge.net>

                       https://lists.sourceforge.net/lists/listinfo/mesa3d-users




       ------------------------------------------------------------------------------

       _______________________________________________
       Mesa3d-users mailing list
       Mesa3d-users@lists.sourceforge.net
       <mailto:Mesa3d-users@lists.sourceforge.net>        .