From: Jianrong S. <jia...@gm...> - 2009-06-24 22:04:13
|
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? Thanks, Jianrong |
From: Brian P. <br...@vm...> - 2009-06-24 22:24:50
|
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 |
From: Jianrong S. <jia...@gm...> - 2009-07-17 22:21:05
|
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...> 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 > > |
From: Karl S. <kar...@gm...> - 2009-07-21 05:47:27
|
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...>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...> 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... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > |
From: Jianrong S. <jia...@gm...> - 2009-07-21 18:25:03
|
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...> 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...> > 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...> 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... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > |
From: Karl S. <kar...@gm...> - 2009-07-21 18:46:10
|
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...>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...> > 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...> > > 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...> 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... > >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users > > > > > |
From: Jianrong S. <jia...@gm...> - 2009-07-21 18:49:40
|
Please go ahead and submit patches as you see fit. On Tue, Jul 21, 2009 at 12:46 PM, Karl Schultz<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...> > 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...> >> 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...> >> > 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...> 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... >> >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> > >> > > > |
From: Brian P. <br...@vm...> - 2009-07-27 19:46:38
|
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...> 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...> >> 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...> >>> 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...> >>>> 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...> 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... >>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>>> >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Mesa3d-users mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/mesa3d-users > . > |
From: Karl S. <kar...@gm...> - 2009-07-27 20:27:39
|
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...> 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...> >> 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...> >>> 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... >>>> > >>>> 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...> >>>>> 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...> 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... >>>>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >>>>>> >>>>> >>>>> >>> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Mesa3d-users mailing list >> Mes...@li... >> https://lists.sourceforge.net/lists/listinfo/mesa3d-users >> . >> >> > |
From: Brian P. <br...@vm...> - 2009-07-27 21:50:52
|
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 > . > > > |
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 >> . >> >> >> >> > |