From: dominic <dom...@so...> - 2004-01-27 06:33:01
|
Hi all, I've compiled the Mesa 6.0 library with VC.NET. Both the libraries and = demos compiled successfully (the configuration is 'Active (Debug)'), = although with a bit warning (I think it doesn't matter anyway, does = it?).=20 And then I tried to run the demo programs. Most of them run = successfully, with a few exceptions: I've got error from the 'fire.exe' = demo, and the 'isosurf.exe' demo. I captured the error messages, and you = can view them in the following links: (from fire.exe) http://dominickwan.netfirms.com/mesa_error1.jpg I just run the exe program and got this message. (from isosurf.exe) http://dominickwan.netfirms.com/mesa_error2.jpg For this case, the program could be executed. The error dialog comes out = when I choose 'glArrayElement' in the pop up menu. All I've done to compile the library is open the .dsw file by VC.NET, = and choose 'Build Solution' to build all of them. Is there any steps = that I've missed, or should I tweak any settings in the compiler? For = your reference, I've put the build log on=20 http://dominickwan.netfirms.com/mesa_buildlog.txt. One more thing to mention is that I can never compile the library in = Release mode. It always stops at 'image.c' without giving me any error = messages... again, could anyone give me some hint on solving this? Thanks in advance. Regards, Dominic |
From: Mikael A. <mik...@te...> - 2004-01-27 07:47:49
|
Hi ! The first problem may or may not be a bug in Mesa, a variable "span" is = being used without having been initialized, this may not be a bug, it = depends a little on the code, it is the boundschecking code in VC that = makes the crash not the code itself (Microsoft has had a few nasty bugs = in their boundschecking code in that past, is it VC 7.0 or 7.1 ?). The second problem is weird, it happens when you declare a function with = incorrect calling convention, but most of the time it cannot happen = because different calling conventions usually have different name = mangling, I don't have a clue to what the problem is, but some function = prefix __declspec may be missing or something like that. Mikael ----- Original Message -----=20 From: dominic=20 To: mes...@li...=20 Sent: Tuesday, January 27, 2004 7:32 AM Subject: [Mesa3d-users] Mesa dlls in Windows XP, compiled with VC.NET Hi all, I've compiled the Mesa 6.0 library with VC.NET. Both the libraries and = demos compiled successfully (the configuration is 'Active (Debug)'), = although with a bit warning (I think it doesn't matter anyway, does = it?).=20 And then I tried to run the demo programs. Most of them run = successfully, with a few exceptions: I've got error from the 'fire.exe' = demo, and the 'isosurf.exe' demo. I captured the error messages, and you = can view them in the following links: (from fire.exe) http://dominickwan.netfirms.com/mesa_error1.jpg I just run the exe program and got this message. (from isosurf.exe) http://dominickwan.netfirms.com/mesa_error2.jpg For this case, the program could be executed. The error dialog comes = out when I choose 'glArrayElement' in the pop up menu. All I've done to compile the library is open the .dsw file by VC.NET, = and choose 'Build Solution' to build all of them. Is there any steps = that I've missed, or should I tweak any settings in the compiler? For = your reference, I've put the build log on=20 http://dominickwan.netfirms.com/mesa_buildlog.txt. One more thing to mention is that I can never compile the library in = Release mode. It always stops at 'image.c' without giving me any error = messages... again, could anyone give me some hint on solving this? Thanks in advance. Regards, Dominic |
From: Karl S. <k.w...@co...> - 2004-01-27 15:52:46
|
At 02:32 PM 1/27/2004 +0800, dominic wrote: >Hi all, > >I've compiled the Mesa 6.0 library with VC.NET. Both the libraries and >demos compiled successfully (the configuration is 'Active (Debug)'), >although with a bit warning (I think it doesn't matter anyway, does it?). The GLU libraries will generate a bunch of warnings when compiling the C++ parts of GLU. There are a couple of issues here. 1) The C++ files in the GLU lib use the file extension ".cc". The Visual Studio (ver 6) does not recognize this filetype as a C++ file and so I had to create some really clumsy custom build steps. There is a way to convince the Visual Studio to treat .cc files as C++, but it involves some registry hacks and other unnatural actions. I hope to improve this situation in the future. 2) The warnings themselves can probably be suppressed with some compiler options, but I didn't look into it that closely. If someone can figure it out, I'll be glad to make the changes. > >And then I tried to run the demo programs. Most of them run successfully, >with a few exceptions: I've got error from the 'fire.exe' demo, and the >'isosurf.exe' demo. I captured the error messages, and you can view them >in the following links: > >(from fire.exe) ><http://dominickwan.netfirms.com/mesa_error1.jpg>http://dominickwan.netfirms.com/mesa_error1.jpg >I just run the exe program and got this message. A change was recently made to the Mesa source code to replace a malloc() call with calloc(). When you run a debug build, the allocated storage is filled with a pattern and the code checks to see if the data has ever been written to before it is first accessed. You might try getting/making this change: Log message: replace MALLOC w/ CALLOC to silence valgrind warnings Modified files: Mesa/src/mesa/tnl/: Tag: mesa_6_0_branch t_vertex.c Revision Changes Path 1.10.2.1 +1 -1 Mesa/src/mesa/tnl/t_vertex.c I only tested the build with VC 6, so that is why it didn't get noticed sooner. I have VC 7 now, so I will start using it as well. > >(from isosurf.exe) ><http://dominickwan.netfirms.com/mesa_error2.jpg>http://dominickwan.netfirms.com/mesa_error2.jpg >For this case, the program could be executed. The error dialog comes out >when I choose 'glArrayElement' in the pop up menu. I'll look into this. As another poster said, it is very likely a mismatched cdecl/stdcall issue. My first guess after a VERY quick look at the code is that the typedefs for array_func and texarray_func need to be changed to include GLAPIENTRY in src/mesa/main/api_arrayelt.c. You might try that to see how it works out until I can make the final fix. > >All I've done to compile the library is open the .dsw file by VC.NET, and >choose 'Build Solution' to build all of them. Is there any steps that I've >missed, or should I tweak any settings in the compiler? For your >reference, I've put the build log on ><http://dominickwan.netfirms.com/mesa_buildlog.txt>http://dominickwan.netfirms.com/mesa_buildlog.txt. No, you did it right. I just was unable to check everything out on VC 7. The projects were constructed on VC 6. The OPT:NOWIN98 problem is due to something that changed between VC 6 and VC 7. I'll have to look into that one too. > >One more thing to mention is that I can never compile the library in >Release mode. It always stops at 'image.c' without giving me any error >messages... again, could anyone give me some hint on solving this? Gee, I don't know about that one. I'll look at it. There must be some clue as to what happened. Do the project files and settings look OK, especially as you compare debug vs release? Karl |
From: dominic <dom...@so...> - 2004-01-28 06:29:44
|
Thanks for your replies! I've got part of the problem solved. Karl Schultz wrote: > At 02:32 PM 1/27/2004 +0800, dominic wrote: > >> Hi all, >> >> I've compiled the Mesa 6.0 library with VC.NET. Both the libraries >> and demos compiled successfully (the configuration is 'Active >> (Debug)'), although with a bit warning (I think it doesn't matter >> anyway, does it?). > > > > The GLU libraries will generate a bunch of warnings when compiling the > C++ parts of GLU. There are a couple of issues here. > 1) The C++ files in the GLU lib use the file extension ".cc". The > Visual Studio (ver 6) does not recognize this filetype as a C++ file > and so I had to create some really clumsy custom build steps. There > is a way to convince the Visual Studio to treat .cc files as C++, but > it involves some registry hacks and other unnatural actions. I hope > to improve this situation in the future. > 2) The warnings themselves can probably be suppressed with some > compiler options, but I didn't look into it that closely. If someone > can figure it out, I'll be glad to make the changes. I added this line into gluos.h #pragma warning(disable : 4291) and the warning about the delete operator disappeared. Hope this help... > A change was recently made to the Mesa source code to replace a > malloc() call with calloc(). When you run a debug build, the > allocated storage is filled with a pattern and the code checks to see > if the data has ever been written to before it is first accessed. > > <cut> > > I only tested the build with VC 6, so that is why it didn't get > noticed sooner. I have VC 7 now, so I will start using it as well. Have no time to look into this... I'll try this tonight. >> (from isosurf.exe) >> http://dominickwan.netfirms.com/mesa_error2.jpg >> For this case, the program could be executed. The error dialog comes >> out when I choose 'glArrayElement' in the pop up menu. > > > I'll look into this. As another poster said, it is very likely a > mismatched cdecl/stdcall issue. My first guess after a VERY quick > look at the code is that the typedefs for array_func and texarray_func > need to be changed to include GLAPIENTRY in > src/mesa/main/api_arrayelt.c. You might try that to see how it works > out until I can make the final fix. I tried to include GLAPIENTRY to the lines, and it works! At least the program didn't crash when I select glArrayElement. But there's another problem (possibly related to this): I tried the DLL on the "Displayment Texture" demo from http://frustum.org/3d. The program runs, but only the texture font and the particle are rendered, leaving the rest of the scene blanked out. I skimmed through the source code and found that the scene is drawn using glDrawArrays, while the particle is drawn with glVertex*. Didn't trace through the program though, so I'm not really sure whether this is the problem source. (Anyway I think someone else has reported this in the forum too.) >> All I've done to compile the library is open the .dsw file by VC.NET, >> and choose 'Build Solution' to build all of them. Is there any steps >> that I've missed, or should I tweak any settings in the compiler? >> For your reference, I've put the build log on >> http://dominickwan.netfirms.com/mesa_buildlog.txt. > > > > No, you did it right. I just was unable to check everything out on VC > 7. The projects were constructed on VC 6. > > The OPT:NOWIN98 problem is due to something that changed between VC 6 > and VC 7. I'll have to look into that one too. > >> >> One more thing to mention is that I can never compile the library in >> Release mode. It always stops at 'image.c' without giving me any >> error messages... again, could anyone give me some hint on solving this? > > > Gee, I don't know about that one. I'll look at it. There must be > some clue as to what happened. Do the project files and settings look > OK, especially as you compare debug vs release? Again, no enough time for this yet. I'll report on these later... Regards, Dominic |
From: Karl S. <k.w...@co...> - 2004-01-28 18:09:39
|
At 02:29 PM 1/28/2004 +0800, dominic wrote: >Thanks for your replies! I've got part of the problem solved. > >Karl Schultz wrote: > >>At 02:32 PM 1/27/2004 +0800, dominic wrote: >> >>>Hi all, >>> >>>I've compiled the Mesa 6.0 library with VC.NET. Both the libraries and >>>demos compiled successfully (the configuration is 'Active (Debug)'), >>>although with a bit warning (I think it doesn't matter anyway, does it?). >> >> >> >>The GLU libraries will generate a bunch of warnings when compiling the >>C++ parts of GLU. There are a couple of issues here. >>1) The C++ files in the GLU lib use the file extension ".cc". The Visual >>Studio (ver 6) does not recognize this filetype as a C++ file and so I >>had to create some really clumsy custom build steps. There is a way to >>convince the Visual Studio to treat .cc files as C++, but it involves >>some registry hacks and other unnatural actions. I hope to improve this >>situation in the future. >>2) The warnings themselves can probably be suppressed with some compiler >>options, but I didn't look into it that closely. If someone can figure >>it out, I'll be glad to make the changes. > >I added this line into gluos.h >#pragma warning(disable : 4291) >and the warning about the delete operator disappeared. Hope this help... Yes, thanks. I'm a little worried about fixing it this way since we didn't get these errors with the old build system (makefiles instead of projects). I'll look into it some more in order to see what really changed. I don't think that the code changed very much, so I think the build files are part of the reason. >>A change was recently made to the Mesa source code to replace a malloc() >>call with calloc(). When you run a debug build, the allocated storage is >>filled with a pattern and the code checks to see if the data has ever >>been written to before it is first accessed. >> >><cut> >> >>I only tested the build with VC 6, so that is why it didn't get noticed >>sooner. I have VC 7 now, so I will start using it as well. > >Have no time to look into this... I'll try this tonight. > >>>(from isosurf.exe) >>>http://dominickwan.netfirms.com/mesa_error2.jpg >>>For this case, the program could be executed. The error dialog comes out >>>when I choose 'glArrayElement' in the pop up menu. >> >> >>I'll look into this. As another poster said, it is very likely a >>mismatched cdecl/stdcall issue. My first guess after a VERY quick look >>at the code is that the typedefs for array_func and texarray_func need to >>be changed to include GLAPIENTRY in src/mesa/main/api_arrayelt.c. You >>might try that to see how it works out until I can make the final fix. > >I tried to include GLAPIENTRY to the lines, and it works! >At least the program didn't crash when I select glArrayElement. > >But there's another problem (possibly related to this): >I tried the DLL on the "Displayment Texture" demo from http://frustum.org/3d. >The program runs, but only the texture font and the particle are rendered, >leaving the rest of the scene blanked out. >I skimmed through the source code and found that the scene is drawn using >glDrawArrays, while the particle is drawn with glVertex*. Didn't trace >through the program though, so I'm not really sure whether this is the >problem source. > >(Anyway I think someone else has reported this in the forum too.) I'll keep all this in mind when I go to fix it, thanks. >>>All I've done to compile the library is open the .dsw file by VC.NET, >>>and choose 'Build Solution' to build all of them. Is there any steps >>>that I've missed, or should I tweak any settings in the compiler? >>>For your reference, I've put the build log on >>>http://dominickwan.netfirms.com/mesa_buildlog.txt. >> >> >> >>No, you did it right. I just was unable to check everything out on VC >>7. The projects were constructed on VC 6. >> >>The OPT:NOWIN98 problem is due to something that changed between VC 6 and >>VC 7. I'll have to look into that one too. >> >>> >>>One more thing to mention is that I can never compile the library in >>>Release mode. It always stops at 'image.c' without giving me any error >>>messages... again, could anyone give me some hint on solving this? >> >> >>Gee, I don't know about that one. I'll look at it. There must be some >>clue as to what happened. Do the project files and settings look OK, >>especially as you compare debug vs release? > >Again, no enough time for this yet. I'll report on these later... This will be really easy to fix by modifying the #if tests that turn on this pragma. I think I can handle it. Karl |
From: Karl S. <k.w...@co...> - 2004-01-29 01:34:24
|
At 02:29 PM 1/28/2004 +0800, dominic wrote: >Thanks for your replies! I've got part of the problem solved. > >Karl Schultz wrote: > >>At 02:32 PM 1/27/2004 +0800, dominic wrote: >> >>>Hi all, >>> >>>I've compiled the Mesa 6.0 library with VC.NET. Both the libraries and >>>demos compiled successfully (the configuration is 'Active (Debug)'), >>>although with a bit warning (I think it doesn't matter anyway, does it?). >> I've put some changes into both the main and 6.0 CVS branches to address most of these issues. There are a few type conversion warnings in the main branch due to other changes, and a few minor messages in the Windows builds that I'll clean up in the future. More details below. >>The GLU libraries will generate a bunch of warnings when compiling the >>C++ parts of GLU. There are a couple of issues here. >>1) The C++ files in the GLU lib use the file extension ".cc". The Visual >>Studio (ver 6) does not recognize this filetype as a C++ file and so I >>had to create some really clumsy custom build steps. There is a way to >>convince the Visual Studio to treat .cc files as C++, but it involves >>some registry hacks and other unnatural actions. I hope to improve this >>situation in the future. >>2) The warnings themselves can probably be suppressed with some compiler >>options, but I didn't look into it that closely. If someone can figure >>it out, I'll be glad to make the changes. > >I added this line into gluos.h >#pragma warning(disable : 4291) >and the warning about the delete operator disappeared. Hope this help... The /GX compiler option is a little strange because it has different default values depending on whether you call the compiler from the command line or from the devenv. The old build system was of course command line based. So, I had to do something different with this option now that we're using projects. Please, someone please give me something to do on Linux. :-) >>A change was recently made to the Mesa source code to replace a malloc() >>call with calloc(). When you run a debug build, the allocated storage is >>filled with a pattern and the code checks to see if the data has ever >>been written to before it is first accessed. >> >><cut> >> >>I only tested the build with VC 6, so that is why it didn't get noticed >>sooner. I have VC 7 now, so I will start using it as well. > >Have no time to look into this... I'll try this tonight. I'm assuming that this is fixed. >>>(from isosurf.exe) >>>http://dominickwan.netfirms.com/mesa_error2.jpg >>>For this case, the program could be executed. The error dialog comes out >>>when I choose 'glArrayElement' in the pop up menu. >> >> >>I'll look into this. As another poster said, it is very likely a >>mismatched cdecl/stdcall issue. My first guess after a VERY quick look >>at the code is that the typedefs for array_func and texarray_func need to >>be changed to include GLAPIENTRY in src/mesa/main/api_arrayelt.c. You >>might try that to see how it works out until I can make the final fix. > >I tried to include GLAPIENTRY to the lines, and it works! >At least the program didn't crash when I select glArrayElement. I've applied these fixes and things seem to work ok. >But there's another problem (possibly related to this): >I tried the DLL on the "Displayment Texture" demo from http://frustum.org/3d. >The program runs, but only the texture font and the particle are rendered, >leaving the rest of the scene blanked out. >I skimmed through the source code and found that the scene is drawn using >glDrawArrays, while the particle is drawn with glVertex*. Didn't trace >through the program though, so I'm not really sure whether this is the >problem source. > >(Anyway I think someone else has reported this in the forum too.) I tried the program on my machine with the native OpenGL (Radeon 9700) and the background scene (brick walls) went away too. The Mesa output wasn't all that different from the native, except that I could get some shadow textures to appear when running the native driver by hitting the application keys. But, I didn't know what I was doing or what it is supposed to look like. >>>All I've done to compile the library is open the .dsw file by VC.NET, >>>and choose 'Build Solution' to build all of them. Is there any steps >>>that I've missed, or should I tweak any settings in the compiler? >>>For your reference, I've put the build log on >>>http://dominickwan.netfirms.com/mesa_buildlog.txt. >> >> >> >>No, you did it right. I just was unable to check everything out on VC >>7. The projects were constructed on VC 6. >> >>The OPT:NOWIN98 problem is due to something that changed between VC 6 and >>VC 7. I'll have to look into that one too. This should be fixed now. >>> >>>One more thing to mention is that I can never compile the library in >>>Release mode. It always stops at 'image.c' without giving me any error >>>messages... again, could anyone give me some hint on solving this? >> >> >>Gee, I don't know about that one. I'll look at it. There must be some >>clue as to what happened. Do the project files and settings look OK, >>especially as you compare debug vs release? The compiler is just taking a very long time to compile image.c. I let it go for about 7 mins before I gave up. You can work around it by turning off the optimization for that file only in the studio. I'll play with it some more. Karl |