I took a look, and I think that:

gl.h has:

#if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__)
#define __WIN32__

and compiler.h has:

#if defined(_WIN32) && !defined(__WIN32__) && !defined(__CYGWIN__) && !defined(BUILD_FOR_SNAP)
#  define __WIN32__
#  define finite _finite

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.


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. :)


Karl Schultz wrote:
Yeah, someone else opened a bug and I put the patch there.


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?


   Jianrong Shu wrote:

       Please go ahead and submit patches as you see fit.

       On Tue, Jul 21, 2009 at 12:46 PM, Karl
       <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

           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.


           On Tue, Jul 21, 2009 at 12:24 PM, Jianrong Shu
           <jianrong.shu@gmail.com <mailto:jianrong.shu@gmail.com>>


               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?


               On Mon, Jul 20, 2009 at 11:47 PM, Karl


                   It looks like glheader.h (thankfully) got cleaned up
                   quite a bit since
                   In the process, the following was lost:

                   #if defined(_WIN32) && !defined(__WIN32__) &&
                   !defined(__CYGWIN__) &&
                   #  define __WIN32__
                   #  define finite _finite

                   Adding back the above will get you going again.

                   Also, you'll need to:

                   Add to the mesa project:


                   Remove from mesa.def:


                   On Fri, Jul 17, 2009 at 4:20 PM, Jianrong Shu
                   <jianrong.shu@gmail.com <mailto:jianrong.shu@gmail.com>>


                       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
                       1>mesa.lib(s_aaline.obj) : error LNK2001:
                       unresolved external symbol
                       1>mesa.lib(prog_execute.obj) : error LNK2019:
                       unresolved external
                       symbol _finite referenced in function
                       1>mesa.lib(s_triangle.obj) : error LNK2001:
                       unresolved external symbol
                       1>mesa.lib(s_lines.obj) : error LNK2001:
                       unresolved external symbol
                       1>mesa.lib(s_points.obj) : error LNK2001:
                       unresolved external symbol

                       This problem might be caused by some settings in
                       the project file, but
                       I couldn't figure out. Any ideas?


                       On Wed, Jun 24, 2009 at 4:24 PM, Brian
                       <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
                               the following error messages:

                               1>mesa.def : error LNK2001: unresolved
                               external symbol
                               1>mesa.def : error LNK2001: unresolved
                               external symbol
                               1>mesa.def : error LNK2001: unresolved
                               external symbol
                               1>mesa.def : error LNK2001: unresolved
                               external symbol
                               1>mesa.def : error LNK2001: unresolved
                               external symbol

                               I also tried the master branch and the
                               same problem exists. Any fix

                           The Visual Studio project files haven't been
                           actively maintained
                           (we've been using scons on Windows).

                           If you can provide updated project files,
                           that'd be great.  It's just
                           matter of removing references to old/removed
                           files and adding the new


                       Enter the BlackBerry Developer Challenge
                       This is your chance to win up to $100,000 in
                       prizes! For a limited
                       vendors submitting new applications to
                       BlackBerry App World(TM) will
                       the opportunity to enter the BlackBerry
                       Developer Challenge. See full
                       details at: http://p.sf.net/sfu/Challenge
                       Mesa3d-users mailing list



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