From: Sylvain <be...@be...> - 2012-05-13 19:10:51
|
Hi all, Would you agree to add a link to the OpenGL Wikibook on the FreeGLUT website left menu? http://en.wikibooks.org/wiki/OpenGL_Programming Pros: - It's based on FreeGLUT! - True to the free software / open source spirit, it's free documentation (Creative Commons CC-BY-SA) and samples are in the public domain - No prior OpenGL knowledge required, focused on OpenGL(ES) 2 - Anybody can contribute - (I'm one of the main contributors ;)) I think it fits well as companion documentation for FreeGLUT. -- Sylvain |
From: John F. F. <joh...@cy...> - 2012-05-13 22:21:06
|
I would agree to it, definitely. Go ahead. - John F. On 5/13/2012 2:10 PM, Sylvain wrote: > Hi all, > > Would you agree to add a link to the OpenGL Wikibook on the FreeGLUT > website left menu? > > http://en.wikibooks.org/wiki/OpenGL_Programming > > Pros: > - It's based on FreeGLUT! > - True to the free software / open source spirit, > it's free documentation (Creative Commons CC-BY-SA) > and samples are in the public domain > - No prior OpenGL knowledge required, focused on OpenGL(ES) 2 > - Anybody can contribute > - (I'm one of the main contributors ;)) > > I think it fits well as companion documentation for FreeGLUT. > > |
From: Sylvain <be...@be...> - 2012-05-14 17:42:44
|
Hi, Thanks, it's online :) - Sylvain On Sun, May 13, 2012 at 05:20:48PM -0500, John F. Fay wrote: > I would agree to it, definitely. Go ahead. > > - John F. > > > On 5/13/2012 2:10 PM, Sylvain wrote: > > Hi all, > > > > Would you agree to add a link to the OpenGL Wikibook on the FreeGLUT > > website left menu? > > > > http://en.wikibooks.org/wiki/OpenGL_Programming > > > > Pros: > > - It's based on FreeGLUT! > > - True to the free software / open source spirit, > > it's free documentation (Creative Commons CC-BY-SA) > > and samples are in the public domain > > - No prior OpenGL knowledge required, focused on OpenGL(ES) 2 > > - Anybody can contribute > > - (I'm one of the main contributors ;)) > > > > I think it fits well as companion documentation for FreeGLUT. |
From: John F. F. <joh...@cy...> - 2012-05-15 02:27:23
|
Very good. - John F. On 5/14/2012 12:42 PM, Sylvain wrote: > Hi, > > Thanks, it's online :) > > - Sylvain > > On Sun, May 13, 2012 at 05:20:48PM -0500, John F. Fay wrote: > >> I would agree to it, definitely. Go ahead. >> >> - John F. >> >> >> |
From: Diederick C. N. <dc...@gm...> - 2012-05-21 10:14:05
|
Hi All, Ok, I have fixed the sinf etc problem, as discussed. I am having trouble adding the d postfix to the debug builds. I have done what is suggested in the emails here. Everything buils fine then. However, when starting any of the demo builds with shared linking to freeglut, i get the error that freeglut.dll cannot be found. The problem here is that these should be searching for freeglutd.dll... I seem to have traced the problem down to the module definition (.def) file, which defines the library name as freeglut. changing that (the first line) to freeglutd fixes the problem. But that of course breaks the release build. So we're having a bit of a catch 22 here. The .def file is only needed for 32bit msvc, as far as i understand. It would be great if we can figure out a way to do without it. Also, do we want to add a d suffix for all debug builds on all platforms? The attached path is doing it only for MSVC/windows. Best, Dee On Wed, May 16, 2012 at 10:29 PM, Geoff McLane <ub...@ge...> wrote: > 2. Adding a post fix to Debug builds > ==================================== > > For developer purposes could you consider > adding something like > > if(WIN32 AND MSVC) > set( CMAKE_DEBUG_POSTFIX "d" ) > endif(WIN32 AND MSVC) > > As you know in MSVC windows building we > ALWAYS have at least 2 versions - which are > well separated during the build like - > .../lib/release/freeglut.lib > .../lib/debug/freeglut.lib > > But if you then install them into some > project 3rdparty folder like - > .../project > .../3rdparty/lib/freeglut.lib > the last installed will overwrite any previous. > > I can run cmake adding this on the command > line - > cmake %SRC% -DCMAKE_DEBUG_POSTFIX="d" \ > -DCMAKE_INSTALL_PREFIX=.../3rdparty ... etc > > Now this nearly works and generates a freeglutd.lib > for debug, but then the demo debug builds fail, > saying can not find freeglut.lib, while they > should be now using freeglutd.lib... > > I found this is a problem in freeglut_std.h. If > you employ the above 'd' postfix then the > macro in freeglut_std.h must be expanded to > comply adding - > > # ifdef NDEBUG > # pragma comment (lib, "freeglut_static.lib") > # else > # pragma comment (lib, "freeglut_staticd.lib") > # endif > and > # ifdef NDEBUG > # pragma comment (lib, "freeglut.lib") > # else > # pragma comment (lib, "freeglutd.lib") > # endif > > You may also want to adjust the README.win32 to > match, but usually the 'd' debug versions are > only used by developers, so maybe this is not > required... |
From: Geoff M. <ub...@ge...> - 2012-05-16 14:29:38
|
Hi, Wow, a BIG thanks for adding cmake support ;=)) This makes things very EASY... A few small things with svn of today - This is in XP WIN32 MSVC8 (2005). 1. Using C++ in C source ======================== When trying to build the demos, multi-touch.c uses some C++ constructions while it is only C. In onDisplay() there are some gl function calls then a declaration of float square[] = { and a little later int d; for (d = 0; ... etc Now while this IS allowed in C++, in MSVC C all variable declarations MUST occur before any function calls, etc... I in fact moved the float square[] = { declaration outside the function, adding it as a static, and the int d; up to the top. The later int c; declaration is ok because it is the first declaration in a new { } context... Also multi-touch.c emits about 8 C4244 MSVC8 warnings - like conversion from 'int' to 'float', and 2 C4113 - diff in parameter list, but this is just MS being very pedantic ;=)) void (__cdecl *)() vs void (__cdecl *)(void) These can be ignored. 2. Adding a post fix to Debug builds ==================================== For developer purposes could you consider adding something like if(WIN32 AND MSVC) set( CMAKE_DEBUG_POSTFIX "d" ) endif(WIN32 AND MSVC) As you know in MSVC windows building we ALWAYS have at least 2 versions - which are well separated during the build like - .../lib/release/freeglut.lib .../lib/debug/freeglut.lib But if you then install them into some project 3rdparty folder like - .../project .../3rdparty/lib/freeglut.lib the last installed will overwrite any previous. I can run cmake adding this on the command line - cmake %SRC% -DCMAKE_DEBUG_POSTFIX="d" \ -DCMAKE_INSTALL_PREFIX=.../3rdparty ... etc Now this nearly works and generates a freeglutd.lib for debug, but then the demo debug builds fail, saying can not find freeglut.lib, while they should be now using freeglutd.lib... I found this is a problem in freeglut_std.h. If you employ the above 'd' postfix then the macro in freeglut_std.h must be expanded to comply adding - # ifdef NDEBUG # pragma comment (lib, "freeglut_static.lib") # else # pragma comment (lib, "freeglut_staticd.lib") # endif and # ifdef NDEBUG # pragma comment (lib, "freeglut.lib") # else # pragma comment (lib, "freeglutd.lib") # endif You may also want to adjust the README.win32 to match, but usually the 'd' debug versions are only used by developers, so maybe this is not required... 3. Perhaps this is a cmake 'bug'... ================================ You search for some math functions like - CHECK_FUNCTION_EXISTS(sinf HAVE_SINF) but they are NOT found in my case... so remain undefined in the generated config.h Then during the compile this generates a warning .../fg_geometry.c(35) : warning C4005: \ 'sinf' : macro redefinition Because the function check fails, thus HAVE_SINF remains undefined... but this MACRO does exist in - C:\Program Files\Microsoft Visual Studio 8\ VC\include\math.h at about line 307... As stated maybe this is a cmake problem not correctly testing for 'sinf'... And with the above C/C++ and POSTIFX changes everything built and installed easily... My svn diff shown below... Thanks... HTH, Regards, Geoff. Files effected: CMakeLists.txt include/freeglut_std.h progs/demos/multi-touch/multi-touch.c <SVN_Diff> Index: include/GL/freeglut_std.h =================================================================== --- include/GL/freeglut_std.h (revision 1318) +++ include/GL/freeglut_std.h (working copy) @@ -64,31 +64,32 @@ /* Windows static library */ # ifdef FREEGLUT_STATIC - # define FGAPI # define FGAPIENTRY - /* Link with Win32 static freeglut lib */ # if FREEGLUT_LIB_PRAGMAS -# pragma comment (lib, "freeglut_static.lib") +# ifdef NDEBUG +# pragma comment (lib, "freeglut_static.lib") +# else +# pragma comment (lib, "freeglut_staticd.lib") +# endif # endif - /* Windows shared library (DLL) */ # else - # define FGAPIENTRY __stdcall # if defined(FREEGLUT_EXPORTS) # define FGAPI __declspec(dllexport) # else # define FGAPI __declspec(dllimport) - /* Link with Win32 shared freeglut lib */ # if FREEGLUT_LIB_PRAGMAS -# pragma comment (lib, "freeglut.lib") +# ifdef NDEBUG +# pragma comment (lib, "freeglut.lib") +# else +# pragma comment (lib, "freeglutd.lib") +# endif # endif - # endif - # endif /* Drag in other Windows libraries as required by FreeGLUT */ Index: progs/demos/multi-touch/multi-touch.c =================================================================== --- progs/demos/multi-touch/multi-touch.c (revision 1318) +++ progs/demos/multi-touch/multi-touch.c (working copy) @@ -41,20 +41,20 @@ } *Cursor; struct cursor cursors[NUM_DEVICES][NUM_CURSORS]; -void onDisplay() { - glClearColor(0,0,0,1); - glClear(GL_COLOR_BUFFER_BIT); - - float square[] = { +static float square[] = { -.5, -.5, .5, -.5, -.5, .5, .5, .5, }; +void onDisplay() { + int d; + glClearColor(0,0,0,1); + glClear(GL_COLOR_BUFFER_BIT); + glEnableClientState(GL_VERTEX_ARRAY); glVertexPointer(2, GL_FLOAT, 0, square); - int d; for (d = 0; d < NUM_DEVICES; d++) { int c; for (c = 0; d < NUM_DEVICES; d++) { Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 1318) +++ CMakeLists.txt (working copy) @@ -197,6 +197,9 @@ IF(WIN32) # hide insecure CRT warnings, common practice ADD_DEFINITIONS(-D_CRT_SECURE_NO_WARNINGS) + IF(MSVC) + SET( CMAKE_DEBUG_POSTFIX "d" ) + ENDIF(MSVC) ENDIF() IF(CMAKE_COMPILER_IS_GNUCC) </SVN_Diff> |
From: John F. F. <joh...@cy...> - 2012-05-17 11:54:20
|
I agree thoroughly on the first point. I think the second point is a good idea. What do others think? I also agree thoroughly on the third point. I keep taking out "sinf", "cosf", and "sqrtf" calls and they keep creeping back in. - John F. On 5/16/2012 9:29 AM, Geoff McLane wrote: > Hi, > > Wow, a BIG thanks for adding cmake support ;=)) > This makes things very EASY... > > A few small things with svn of today - > This is in XP WIN32 MSVC8 (2005). > > 1. Using C++ in C source > ======================== > > When trying to build the demos, > multi-touch.c uses some C++ constructions > while it is only C. > > In onDisplay() there are some gl function > calls then a declaration of > float square[] = { > and a little later > int d; > for (d = 0; ... etc > > Now while this IS allowed in C++, in MSVC > C all variable declarations MUST occur > before any function calls, etc... > > I in fact moved the float square[] = { > declaration outside the function, adding it > as a static, and the int d; up to the top. > > The later int c; declaration is ok because > it is the first declaration in a new { } > context... > > Also multi-touch.c emits about 8 C4244 > MSVC8 warnings - like conversion from > 'int' to 'float', and 2 C4113 - diff in > parameter list, but this is just MS being > very pedantic ;=)) > > void (__cdecl *)() vs void (__cdecl *)(void) > > These can be ignored. > > 2. Adding a post fix to Debug builds > ==================================== > > For developer purposes could you consider > adding something like > > if(WIN32 AND MSVC) > set( CMAKE_DEBUG_POSTFIX "d" ) > endif(WIN32 AND MSVC) > > As you know in MSVC windows building we > ALWAYS have at least 2 versions - which are > well separated during the build like - > .../lib/release/freeglut.lib > .../lib/debug/freeglut.lib > > But if you then install them into some > project 3rdparty folder like - > .../project > .../3rdparty/lib/freeglut.lib > the last installed will overwrite any previous. > > I can run cmake adding this on the command > line - > cmake %SRC% -DCMAKE_DEBUG_POSTFIX="d" \ > -DCMAKE_INSTALL_PREFIX=.../3rdparty ... etc > > Now this nearly works and generates a freeglutd.lib > for debug, but then the demo debug builds fail, > saying can not find freeglut.lib, while they > should be now using freeglutd.lib... > > I found this is a problem in freeglut_std.h. If > you employ the above 'd' postfix then the > macro in freeglut_std.h must be expanded to > comply adding - > > # ifdef NDEBUG > # pragma comment (lib, "freeglut_static.lib") > # else > # pragma comment (lib, "freeglut_staticd.lib") > # endif > and > # ifdef NDEBUG > # pragma comment (lib, "freeglut.lib") > # else > # pragma comment (lib, "freeglutd.lib") > # endif > > You may also want to adjust the README.win32 to > match, but usually the 'd' debug versions are > only used by developers, so maybe this is not > required... > > 3. Perhaps this is a cmake 'bug'... > ================================ > > You search for some math functions like - > CHECK_FUNCTION_EXISTS(sinf HAVE_SINF) > but they are NOT found in my case... so remain > undefined in the generated config.h > > Then during the compile this generates a warning > .../fg_geometry.c(35) : warning C4005: \ > 'sinf' : macro redefinition > > Because the function check fails, thus > HAVE_SINF remains undefined... but this MACRO > does exist in - > C:\Program Files\Microsoft Visual Studio 8\ > VC\include\math.h > at about line 307... > > As stated maybe this is a cmake problem not > correctly testing for 'sinf'... > > And with the above C/C++ and POSTIFX changes > everything built and installed easily... > > My svn diff shown below... > > Thanks... > > HTH, > > Regards, > Geoff. > > Files effected: > CMakeLists.txt > include/freeglut_std.h > progs/demos/multi-touch/multi-touch.c > > <SVN_Diff> > Index: include/GL/freeglut_std.h > =================================================================== > --- include/GL/freeglut_std.h (revision 1318) > +++ include/GL/freeglut_std.h (working copy) > @@ -64,31 +64,32 @@ > > /* Windows static library */ > # ifdef FREEGLUT_STATIC > - > # define FGAPI > # define FGAPIENTRY > - > /* Link with Win32 static freeglut lib */ > # if FREEGLUT_LIB_PRAGMAS > -# pragma comment (lib, "freeglut_static.lib") > +# ifdef NDEBUG > +# pragma comment (lib, "freeglut_static.lib") > +# else > +# pragma comment (lib, "freeglut_staticd.lib") > +# endif > # endif > - > /* Windows shared library (DLL) */ > # else > - > # define FGAPIENTRY __stdcall > # if defined(FREEGLUT_EXPORTS) > # define FGAPI __declspec(dllexport) > # else > # define FGAPI __declspec(dllimport) > - > /* Link with Win32 shared freeglut lib */ > # if FREEGLUT_LIB_PRAGMAS > -# pragma comment (lib, "freeglut.lib") > +# ifdef NDEBUG > +# pragma comment (lib, "freeglut.lib") > +# else > +# pragma comment (lib, "freeglutd.lib") > +# endif > # endif > - > # endif > - > # endif > > /* Drag in other Windows libraries as required by FreeGLUT */ > Index: progs/demos/multi-touch/multi-touch.c > =================================================================== > --- progs/demos/multi-touch/multi-touch.c (revision 1318) > +++ progs/demos/multi-touch/multi-touch.c (working copy) > @@ -41,20 +41,20 @@ > } *Cursor; > struct cursor cursors[NUM_DEVICES][NUM_CURSORS]; > > -void onDisplay() { > - glClearColor(0,0,0,1); > - glClear(GL_COLOR_BUFFER_BIT); > - > - float square[] = { > +static float square[] = { > -.5, -.5, > .5, -.5, > -.5, .5, > .5, .5, > }; > > +void onDisplay() { > + int d; > + glClearColor(0,0,0,1); > + glClear(GL_COLOR_BUFFER_BIT); > + > glEnableClientState(GL_VERTEX_ARRAY); > glVertexPointer(2, GL_FLOAT, 0, square); > - int d; > for (d = 0; d< NUM_DEVICES; d++) { > int c; > for (c = 0; d< NUM_DEVICES; d++) { > Index: CMakeLists.txt > =================================================================== > --- CMakeLists.txt (revision 1318) > +++ CMakeLists.txt (working copy) > @@ -197,6 +197,9 @@ > IF(WIN32) > # hide insecure CRT warnings, common practice > ADD_DEFINITIONS(-D_CRT_SECURE_NO_WARNINGS) > + IF(MSVC) > + SET( CMAKE_DEBUG_POSTFIX "d" ) > + ENDIF(MSVC) > ENDIF() > > IF(CMAKE_COMPILER_IS_GNUCC) > </SVN_Diff> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > |
From: Diederick C. N. <dc...@gm...> - 2012-05-17 12:34:58
|
I'm good on all three too. And for the sinf/cosf/sqrtf cases, I guess we'll go down the route of simply doing our own casting so it works everywhere (thanks for testing on VC8!) I'm in transit, so anybody feel free to commit these, or I'll do it in a few days. Best, Dee On Thu, May 17, 2012 at 7:53 PM, John F. Fay <joh...@cy...> wrote: > I agree thoroughly on the first point. > > I think the second point is a good idea. What do others think? > > I also agree thoroughly on the third point. I keep taking out "sinf", > "cosf", and "sqrtf" calls and they keep creeping back in. > > - John F. > > On 5/16/2012 9:29 AM, Geoff McLane wrote: >> Hi, >> >> Wow, a BIG thanks for adding cmake support ;=)) >> This makes things very EASY... >> >> A few small things with svn of today - >> This is in XP WIN32 MSVC8 (2005). >> >> 1. Using C++ in C source >> ======================== >> >> When trying to build the demos, >> multi-touch.c uses some C++ constructions >> while it is only C. >> >> In onDisplay() there are some gl function >> calls then a declaration of >> float square[] = { >> and a little later >> int d; >> for (d = 0; ... etc >> >> Now while this IS allowed in C++, in MSVC >> C all variable declarations MUST occur >> before any function calls, etc... >> >> I in fact moved the float square[] = { >> declaration outside the function, adding it >> as a static, and the int d; up to the top. >> >> The later int c; declaration is ok because >> it is the first declaration in a new { } >> context... >> >> Also multi-touch.c emits about 8 C4244 >> MSVC8 warnings - like conversion from >> 'int' to 'float', and 2 C4113 - diff in >> parameter list, but this is just MS being >> very pedantic ;=)) >> >> void (__cdecl *)() vs void (__cdecl *)(void) >> >> These can be ignored. >> >> 2. Adding a post fix to Debug builds >> ==================================== >> >> For developer purposes could you consider >> adding something like >> >> if(WIN32 AND MSVC) >> set( CMAKE_DEBUG_POSTFIX "d" ) >> endif(WIN32 AND MSVC) >> >> As you know in MSVC windows building we >> ALWAYS have at least 2 versions - which are >> well separated during the build like - >> .../lib/release/freeglut.lib >> .../lib/debug/freeglut.lib >> >> But if you then install them into some >> project 3rdparty folder like - >> .../project >> .../3rdparty/lib/freeglut.lib >> the last installed will overwrite any previous. >> >> I can run cmake adding this on the command >> line - >> cmake %SRC% -DCMAKE_DEBUG_POSTFIX="d" \ >> -DCMAKE_INSTALL_PREFIX=.../3rdparty ... etc >> >> Now this nearly works and generates a freeglutd.lib >> for debug, but then the demo debug builds fail, >> saying can not find freeglut.lib, while they >> should be now using freeglutd.lib... >> >> I found this is a problem in freeglut_std.h. If >> you employ the above 'd' postfix then the >> macro in freeglut_std.h must be expanded to >> comply adding - >> >> # ifdef NDEBUG >> # pragma comment (lib, "freeglut_static.lib") >> # else >> # pragma comment (lib, "freeglut_staticd.lib") >> # endif >> and >> # ifdef NDEBUG >> # pragma comment (lib, "freeglut.lib") >> # else >> # pragma comment (lib, "freeglutd.lib") >> # endif >> >> You may also want to adjust the README.win32 to >> match, but usually the 'd' debug versions are >> only used by developers, so maybe this is not >> required... >> >> 3. Perhaps this is a cmake 'bug'... >> ================================ >> >> You search for some math functions like - >> CHECK_FUNCTION_EXISTS(sinf HAVE_SINF) >> but they are NOT found in my case... so remain >> undefined in the generated config.h >> >> Then during the compile this generates a warning >> .../fg_geometry.c(35) : warning C4005: \ >> 'sinf' : macro redefinition >> >> Because the function check fails, thus >> HAVE_SINF remains undefined... but this MACRO >> does exist in - >> C:\Program Files\Microsoft Visual Studio 8\ >> VC\include\math.h >> at about line 307... >> >> As stated maybe this is a cmake problem not >> correctly testing for 'sinf'... >> >> And with the above C/C++ and POSTIFX changes >> everything built and installed easily... >> >> My svn diff shown below... >> >> Thanks... >> >> HTH, >> >> Regards, >> Geoff. >> >> Files effected: >> CMakeLists.txt >> include/freeglut_std.h >> progs/demos/multi-touch/multi-touch.c >> >> <SVN_Diff> >> Index: include/GL/freeglut_std.h >> =================================================================== >> --- include/GL/freeglut_std.h (revision 1318) >> +++ include/GL/freeglut_std.h (working copy) >> @@ -64,31 +64,32 @@ >> >> /* Windows static library */ >> # ifdef FREEGLUT_STATIC >> - >> # define FGAPI >> # define FGAPIENTRY >> - >> /* Link with Win32 static freeglut lib */ >> # if FREEGLUT_LIB_PRAGMAS >> -# pragma comment (lib, "freeglut_static.lib") >> +# ifdef NDEBUG >> +# pragma comment (lib, "freeglut_static.lib") >> +# else >> +# pragma comment (lib, "freeglut_staticd.lib") >> +# endif >> # endif >> - >> /* Windows shared library (DLL) */ >> # else >> - >> # define FGAPIENTRY __stdcall >> # if defined(FREEGLUT_EXPORTS) >> # define FGAPI __declspec(dllexport) >> # else >> # define FGAPI __declspec(dllimport) >> - >> /* Link with Win32 shared freeglut lib */ >> # if FREEGLUT_LIB_PRAGMAS >> -# pragma comment (lib, "freeglut.lib") >> +# ifdef NDEBUG >> +# pragma comment (lib, "freeglut.lib") >> +# else >> +# pragma comment (lib, "freeglutd.lib") >> +# endif >> # endif >> - >> # endif >> - >> # endif >> >> /* Drag in other Windows libraries as required by FreeGLUT */ >> Index: progs/demos/multi-touch/multi-touch.c >> =================================================================== >> --- progs/demos/multi-touch/multi-touch.c (revision 1318) >> +++ progs/demos/multi-touch/multi-touch.c (working copy) >> @@ -41,20 +41,20 @@ >> } *Cursor; >> struct cursor cursors[NUM_DEVICES][NUM_CURSORS]; >> >> -void onDisplay() { >> - glClearColor(0,0,0,1); >> - glClear(GL_COLOR_BUFFER_BIT); >> - >> - float square[] = { >> +static float square[] = { >> -.5, -.5, >> .5, -.5, >> -.5, .5, >> .5, .5, >> }; >> >> +void onDisplay() { >> + int d; >> + glClearColor(0,0,0,1); >> + glClear(GL_COLOR_BUFFER_BIT); >> + >> glEnableClientState(GL_VERTEX_ARRAY); >> glVertexPointer(2, GL_FLOAT, 0, square); >> - int d; >> for (d = 0; d< NUM_DEVICES; d++) { >> int c; >> for (c = 0; d< NUM_DEVICES; d++) { >> Index: CMakeLists.txt >> =================================================================== >> --- CMakeLists.txt (revision 1318) >> +++ CMakeLists.txt (working copy) >> @@ -197,6 +197,9 @@ >> IF(WIN32) >> # hide insecure CRT warnings, common practice >> ADD_DEFINITIONS(-D_CRT_SECURE_NO_WARNINGS) >> + IF(MSVC) >> + SET( CMAKE_DEBUG_POSTFIX "d" ) >> + ENDIF(MSVC) >> ENDIF() >> >> IF(CMAKE_COMPILER_IS_GNUCC) >> </SVN_Diff> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer >> >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: John T. <nu...@me...> - 2012-05-17 13:04:10
|
On Thu, May 17, 2012 at 06:53:55AM -0500, John F. Fay wrote: > I agree thoroughly on the first point. > > I think the second point is a good idea. What do others think? > > I also agree thoroughly on the third point. I keep taking out "sinf", > "cosf", and "sqrtf" calls and they keep creeping back in. I agree on all points. The creeping sinf/cosf situation is probably due to excessive warnings from visual studio. We should probably lower the warning level a bit, nothing is going to blow up if a double is converted to a float. And no need to ugly-up the place with needless casts either. Just make the warning go away, it's stupid. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: John T. <nu...@me...> - 2012-05-21 13:37:45
|
On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: > > Also, do we want to add a d suffix for all debug builds on all > platforms? The attached path is doing it only for MSVC/windows. Speaking for all UNIX platforms: absolutely not :) -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2012-05-21 14:02:01
|
Hi Geoff, All, On Mon, May 21, 2012 at 9:37 PM, John Tsiombikas <nu...@me...> wrote: > On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: >> >> Also, do we want to add a d suffix for all debug builds on all >> platforms? The attached path is doing it only for MSVC/windows. > > Speaking for all UNIX platforms: absolutely not :) Given the trouble/catch 22 I'm having with this, shall we then just not do it on windows as well then? For freeglut itself, it is always compiled into a bin/Debug or bin/Release path with MSVC. So maybe the developer could make sure to only install from the release path? Also, the debug builds should only be needed for us... Should we by default only have release builds, and have an advanced switch for us developers to only get debug builds? Geoff, how strongly you feel about this being possible? If so, I'd: 1) want to make it optional by a (defaulting to off) switch in CMake, which'd be easy 2) need a solution to the catch 22. Would you have time to look into this? I probably wont get a chance to pursue this further. Best, Dee |
From: John F. F. <joh...@cy...> - 2012-05-22 04:18:50
|
Thank you for fixing the "sinf" problem. If the ".def" file is only used in Windows, would it be possible to put in a "#if defined _DEBUG" statement? Since the *nix and Windows versions behave so differently here already, I have no problem in making them a bit more different. - John F. On 5/21/2012 5:13 AM, Diederick C. Niehorster wrote: > Hi All, > > Ok, I have fixed the sinf etc problem, as discussed. > > I am having trouble adding the d postfix to the debug builds. I have > done what is suggested in the emails here. Everything buils fine then. > However, when starting any of the demo builds with shared linking to > freeglut, i get the error that freeglut.dll cannot be found. The > problem here is that these should be searching for freeglutd.dll... > > I seem to have traced the problem down to the module definition (.def) > file, which defines the library name as freeglut. changing that (the > first line) to freeglutd fixes the problem. But that of course breaks > the release build. > > So we're having a bit of a catch 22 here. The .def file is only needed > for 32bit msvc, as far as i understand. It would be great if we can > figure out a way to do without it. > > Also, do we want to add a d suffix for all debug builds on all > platforms? The attached path is doing it only for MSVC/windows. > > Best, > Dee > |
From: Diederick C. N. <dc...@gm...> - 2012-05-22 14:47:43
|
Hi John, Well, we'd have to generate (or provide) two differnt versions of the .def file, one for release and one for debug builds. There's no preprocessor step, the .def file is use by the linker. Hence I'm thinking adding the d suffix might be too much work, also because debug builds should only be of use to us few freeglut developers and in principle noone else? Hence, Geoff, how important is this to you? Or do you see a better way to take this last hurdle? I have nothing against the d suffix on windows, as long as it doesn't create too much overhead. Best, Dee On Tue, May 22, 2012 at 11:52 AM, John F. Fay <joh...@cy...> wrote: > Thank you for fixing the "sinf" problem. > > If the ".def" file is only used in Windows, would it be possible to put > in a "#if defined _DEBUG" statement? Since the *nix and Windows > versions behave so differently here already, I have no problem in making > them a bit more different. > > - John F. > > > On 5/21/2012 5:13 AM, Diederick C. Niehorster wrote: >> Hi All, >> >> Ok, I have fixed the sinf etc problem, as discussed. >> >> I am having trouble adding the d postfix to the debug builds. I have >> done what is suggested in the emails here. Everything buils fine then. >> However, when starting any of the demo builds with shared linking to >> freeglut, i get the error that freeglut.dll cannot be found. The >> problem here is that these should be searching for freeglutd.dll... >> >> I seem to have traced the problem down to the module definition (.def) >> file, which defines the library name as freeglut. changing that (the >> first line) to freeglutd fixes the problem. But that of course breaks >> the release build. >> >> So we're having a bit of a catch 22 here. The .def file is only needed >> for 32bit msvc, as far as i understand. It would be great if we can >> figure out a way to do without it. >> >> Also, do we want to add a d suffix for all debug builds on all >> platforms? The attached path is doing it only for MSVC/windows. >> >> Best, >> Dee >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Eero P. <epa...@gm...> - 2012-05-23 14:21:57
|
On Tue, May 22, 2012 at 5:47 PM, Diederick C. Niehorster <dc...@gm...> wrote: > Hence I'm thinking adding the d suffix might be too much work, also > because debug builds should only be of use to us few freeglut > developers and in principle noone else? > As a developer i usually link my debug software build with debug versions of the library, and my release versions with the release library. I think that on Windows I need to do this, the build does not work well if the different parts don't use the version of the CRT library. So if I want to use the debug version of that on my debug builds, and a release version on release builds then also my libraries should be built that way. (please tell me if I am wrong). So I think that also "software" (not freeglut) developers might need to compile two library versions. Well and of course, now that I am thinking of it, it is not necessary to have a separate suffix, building the library to different directories would be enough.... Eero > Hence, Geoff, how important is this to you? Or do you see a better way > to take this last hurdle? I have nothing against the d suffix on > windows, as long as it doesn't create too much overhead. > > Best, > Dee > > On Tue, May 22, 2012 at 11:52 AM, John F. Fay <joh...@cy...> wrote: >> Thank you for fixing the "sinf" problem. >> >> If the ".def" file is only used in Windows, would it be possible to put >> in a "#if defined _DEBUG" statement? Since the *nix and Windows >> versions behave so differently here already, I have no problem in making >> them a bit more different. >> >> - John F. >> >> >> On 5/21/2012 5:13 AM, Diederick C. Niehorster wrote: >>> Hi All, >>> >>> Ok, I have fixed the sinf etc problem, as discussed. >>> >>> I am having trouble adding the d postfix to the debug builds. I have >>> done what is suggested in the emails here. Everything buils fine then. >>> However, when starting any of the demo builds with shared linking to >>> freeglut, i get the error that freeglut.dll cannot be found. The >>> problem here is that these should be searching for freeglutd.dll... >>> >>> I seem to have traced the problem down to the module definition (.def) >>> file, which defines the library name as freeglut. changing that (the >>> first line) to freeglutd fixes the problem. But that of course breaks >>> the release build. >>> >>> So we're having a bit of a catch 22 here. The .def file is only needed >>> for 32bit msvc, as far as i understand. It would be great if we can >>> figure out a way to do without it. >>> >>> Also, do we want to add a d suffix for all debug builds on all >>> platforms? The attached path is doing it only for MSVC/windows. >>> >>> Best, >>> Dee >>> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Freeglut-developer mailing list >> Fre...@li... >> https://lists.sourceforge.net/lists/listinfo/freeglut-developer > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Diederick C. N. <dc...@gm...> - 2012-05-25 01:26:05
|
Hi Eero and list, On Wed, May 23, 2012 at 10:21 PM, Eero Pajarre <epa...@gm...> wrote: > > I think that on Windows I need to do this, the build does not work > well if the different parts don't use the version of the CRT library. > So if I want to use the debug version of that on my debug builds, and > a release version on release builds then also my libraries should be > built that way. (please tell me if I am wrong). Good point. And once people start copying the dlls, like Geoff is talking about, building into separate directories is no longer enough. I have found an easy solution to the problem! The problem was the line LIBRARY freeglut in freeglutdll.def, which makes the executabe always look for freeglut.dll, even when freeglutd.dll was built in debug mode. Turns out that line is optional, and if not specified, the linker output file is used as default. So removing it fixes everything! Committed. Geoff, I believe all three of your points are addressed now. Please do test. Best, Dee |
From: Sylvain <be...@be...> - 2012-05-29 07:14:16
|
Hi, On Tue, May 29, 2012 at 07:11:17AM +0100, Martin Payne wrote: > Hi Dee, > > On 27/05/2012 11:41, Diederick C. Niehorster wrote: > > This is a good moment for a question: Are there any other compilers > > than 32bit MSVC that need the .def file? Its currently only defined to > > be used for the various versions MSVC in CMake. > > The linker in MinGW takes a "--kill-at" command line switch which takes > care of exporting undecorated functions. However, it creates an import > library which is broken, and you actually need a def file which contains > *decorated* function names to create the import library correctly! The > easiest way to do it is to build the DLL normally with the "--kill-at" > switch, create a dummy DLL and get the linker to create the def file > with decorated function names, and then use dlltool with this new def > file to create the import library. > > If I remember correctly, using a def file and the > "__declspec(dllexport)" in MinGW results in the DLL exporting both > decorated and undecorated names. It sounds logical to work on ABI compatibility with glut32.dll. However, I wonder if that is still, today, something that our users need, especially if things are this complex. API compatibility might be enough. I was thinking: "Hey, we should generate a .exe linked against glut32.dll and use it as a test case" but then I stopped and thought "Doesn't such a .exe already exist? And if not, why are we bothering in the first place?" :) -- Sylvain |
From: John T. <nu...@me...> - 2012-05-29 13:34:02
|
On Tue, May 29, 2012 at 09:14:05AM +0200, Sylvain wrote: > > I was thinking: > "Hey, we should generate a .exe linked against glut32.dll and use it > as a test case" > but then I stopped and thought > "Doesn't such a .exe already exist? And if not, why are we > bothering in the first place?" > :) Of course, loads. Pretty much every GLUT program on windows out there links with glut32.dll. First result for glut win32 on google returns nate robin's or what's his name port of the original glut, so every person I know who uses glut on windows links with that. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Diederick C. N. <dc...@gm...> - 2012-05-25 01:29:51
|
Hi John and Geoff, On Mon, May 21, 2012 at 9:37 PM, John Tsiombikas <nu...@me...> wrote: > On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: >> >> Also, do we want to add a d suffix for all debug builds on all >> platforms? The attached path is doing it only for MSVC/windows. > > Speaking for all UNIX platforms: absolutely not :) Why is this a windows+MSVC only thing? Wouldn't it be generally useful for the same reasons? Geoff: in case you're not following the list, have a look at the thread. We've had some discussion and all of your suggestions have been implemented. Best, Dee |
From: Sylvain <be...@be...> - 2012-05-25 08:44:06
|
Hi, On Fri, May 25, 2012 at 09:29:45AM +0800, Diederick C. Niehorster wrote: > Hi John and Geoff, > > On Mon, May 21, 2012 at 9:37 PM, John Tsiombikas <nu...@me...> wrote: > > On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: > >> > >> Also, do we want to add a d suffix for all debug builds on all > >> platforms? The attached path is doing it only for MSVC/windows. > > > > Speaking for all UNIX platforms: absolutely not :) > > Why is this a windows+MSVC only thing? Wouldn't it be generally useful > for the same reasons? Usually you need a single debug build. - In most distros, debug symbols are automatically stripped for space reasons - In some distros, debug symbols (without the library) may be available as a separate package, so the debugger can use them. - When you manually compile, developer or not, you just don't need to strip the debug symbols. ('strip' is a widespread compiler utility) TBH I didn't understand the need for this 'd' suffix on windows. I did read your explanation in the other thread but this is opaque to me ;) -- Sylvain |
From: Geoff M. <ub...@ge...> - 2012-05-25 12:15:48
|
-Hi, Sorry I had not been following on the list, and thanks Dee for the direct tickle ;=)) I am still 'developing' full cmake understanding, so please correct me if I say something wrong about cmake... First the cmake library suffix has no effect on unix, and in this context, apple/MAC builds, so can be put for all... or in an if(WIN32 AND MSVC) context... And yes, I can understand that unix people do not get the difference, and WHY the big need in MSVC building ;=)) but please try to be 'tolerant' of the differences... And as someone pointed out I think, this suffix is NOT just for freeglut building, but if I am building a project using freeglut, then I might want to build both Release and Debug for that project... Because I want to Debug MY project... with source level debug view for ALL used 3rdparty libraries... Now, yes, when building my project I can point my project IDE to Release/freeglut.lib, and Debug/freeglut.lib resp., and not have a problem with the mixed CRT things... This is less of a problem with DLL/LIB, where actually the archive LIB part is the same, but IS a BIG problem with static links... read ERROR ;=(( But the usual thing is to 'install' freeglut into some 3rdParty/lib folder, and in this case the Debug MUST have a different name to the Release. Full stop! Regarding the idea of a catch-22 concerning the DEF file, well there are two ways to tell MSVC to build an archive library, LIB, as well as the DLL, and that is - 1. through a DEF file - the OLD way... or 2. through the MS specific __declspec pragma, one for building the library itself, dllexport, and one for importers/users of the library, dllimport. You do not need BOTH, and since you have the pragma, then the DEF file can be dropped. Or else you have to have 2 due to a change in library name in the head... or as you have found, just dropping the name from the DEF. There is another reason to use a DEF file, and that is to create 'alias' names for functions, and/or undecorated names, but I do not think you need, or use this alias, and already use extern "C" to get undecorated names, so again just drop the DEF! And this CMAKE_DEBUG_POSTFIX only effects the library. You need to do more to add the postfix to the demos, which I would suggest using... like set_target_properties( <project> PROPERTIES DEBUG_POSTFIX d ) Anyway, now to look at what has been changed so far... fresh svn co in another machine this time... (a) Ok you put the postfix in if(WIN32 AND MSVC) which is ok, but as indicated not really needed, since it has no effect on the SINGLE library generated in unix. (b) Next thing was to kill the .DEF file addition and generation... I note you already do this when building WIN64, so why keep it for WIN32... Well ok, I created an OPTION option(ADD_WIN32_DEF "Generate and link with a DEF file" OFF) in case 'someone' wants it ON, then twice IF(MSVC AND ADD_WIN32_DEF AND NOT CMAKE_CL_64) (c) Add the postfix for the demos. Luckily this is just one change to the ADD_DEMO MACRO ;=)) YOWEE, building the static and shared libraries went like a breeze ;=)) and got both the rel and the postfix 'd' version... 1 min 10 secs... BUT now note you install the DLL and its LIB in 3rdParty/lib... hmmm, it is more usual to install the LIB in lib, and the DLL in bin. Ah, there is is - you have - IF(BUILD_SHARED_LIBS) INSTALL(TARGETS freeglut DESTINATION lib) ENDIF() That should be - install( TARGETS freeglut RUNTIME DESTINATION bin LIBRARY DESTINATION lib ARCHIVE DESTINATION lib ) Now to enable demo building - 48 secs later - Ok, on the demos the postfix did not work. Not sure why... but maybe that is ok, because they are NOT installed...NO, that was my bad - just a spelling mistake ;=)) Fully trashed my out-of-source build directory, and start it all again - 1 min 53 secs, and I have everything ;=)) I use batch files, and an all command line build... No problems with the sinf - that seems fixed. multi-touch.c still reports 8 x C4113, and 2 x C4114 warnings... It is ok to 'know' that the C4113 given conversion from 'int' to 'float' will not be a problem... but you can also add -wd4113 to the MSVC compile flags and get rid of it. Or add a cast to tell the compiler 'you know' what you are doing ;=)) And the C4114 difference of () versus (void) could be fixed just by making the declaration the SAME as the function ;=)) Why not? Unfortunately out of time today so no time to try running all the demos... tried just bin\Release\shapes.exe bin\Debug\shapesd.exe and no problems with either... bin\Release\Fractals.exe - it ran, but reported ERROR opening file <fractals.dat> but sure that would be ok if I ran it in the folder where fractals.dat exists, or... As usual my current svn diff is attached. One small point, most projects are opting to use cmake lowercase directive while you have chosen uppercase... maybe it looks a little better in lowercase, but is a minor quibble ;=)) And this was all using MSVC10 PRO in Win 7 x64, but only tried the x86 (WIN32) lib versions... Will try to find time to do it all again with with x64, and with MSVC8, and maybe other MSVC versions next week. And YELL if I missed addressing some point, or you want expansion... and will try harder to better monitor this list ;=)) Regards, Geoff. <diff-02.txt> Index: CMakeLists.txt =================================================================== --- CMakeLists.txt (revision 1323) +++ CMakeLists.txt (working copy) @@ -28,6 +28,7 @@ OPTION(FREEGLUT_GLES1 "Use OpenGL ES 1.x (requires EGL)" OFF) OPTION(FREEGLUT_GLES2 "Use OpenGL ES 2.x (requires EGL) (overrides BUILD_GLES1)" OFF) +option(ADD_WIN32_DEF "Generate and link with a DEF file" OFF) SET(FREEGLUT_HEADERS include/GL/freeglut.h @@ -96,7 +97,7 @@ src/mswin/fg_window_mswin.c ${CMAKE_BINARY_DIR}/freeglut.rc # generated below from freeglut.rc.in ) - IF (MSVC AND NOT CMAKE_CL_64) + IF (MSVC AND ADD_WIN32_DEF AND NOT CMAKE_CL_64) # .def file only for 32bit Windows builds (TODO: MSVC only right # now, needed for any other Windows platform?) LIST(APPEND FREEGLUT_SRCS @@ -283,7 +284,7 @@ # we also have to generate freeglut.rc, which contains the version # number CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/freeglut.rc.in ${CMAKE_BINARY_DIR}/freeglut.rc) - IF (MSVC AND NOT CMAKE_CL_64) + IF (MSVC AND ADD_WIN32_DEF AND NOT CMAKE_CL_64) # .def file only for 32bit Windows builds with Visual Studio CONFIGURE_FILE(${CMAKE_SOURCE_DIR}/src/freeglutdll.def.in ${CMAKE_BINARY_DIR}/freeglutdll.def) ENDIF() @@ -356,7 +357,10 @@ ENDIF() IF(BUILD_SHARED_LIBS) - INSTALL(TARGETS freeglut DESTINATION lib) + install(TARGETS freeglut + RUNTIME DESTINATION bin + LIBRARY DESTINATION lib + ARCHIVE DESTINATION lib) ENDIF() IF(BUILD_STATIC_LIBS) INSTALL(TARGETS freeglut_static DESTINATION lib) @@ -385,6 +389,7 @@ TARGET_LINK_LIBRARIES(${name}_static ${DEMO_LIBS} freeglut_static) SET_TARGET_PROPERTIES(${name}_static PROPERTIES COMPILE_FLAGS -DFREEGLUT_STATIC) ENDIF() + set_target_properties( ${name} PROPERTIES DEBUG_POSTFIX d ) ENDIF() ENDMACRO() </diff-02.txt> |
From: John T. <nu...@me...> - 2012-05-25 12:22:35
|
On Fri, May 25, 2012 at 09:29:45AM +0800, Diederick C. Niehorster wrote: > On Mon, May 21, 2012 at 9:37 PM, John Tsiombikas <nu...@me...> wrote: > > On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: > >> > >> Also, do we want to add a d suffix for all debug builds on all > >> platforms? The attached path is doing it only for MSVC/windows. > > > > Speaking for all UNIX platforms: absolutely not :) > > Why is this a windows+MSVC only thing? Wouldn't it be generally useful > for the same reasons? Because windows is the only platform in the universe braindamaged enough to have 4 different mutually incompatible versions of the standard C library: single-threaded, single-threaded DLL, multi-threaded, multi-threaded DLL, single-threaded debug, single-threaded debug DLL, multi-threaded debug, multi-threaded debug DLL. Did I say 4? I meant 8... madness. So it tends to force you to use "debug" libraries with "debug" builds, and "release" libraries with "release" builds, just to make sure you're not using 2-3 different standard libraries in the same application... On other systems the only difference between a "debug" and "non-debug" versions of a library is basically the presence of debugging symbols in it, for source-level debuggers. So it doesn't matter in the least if your application has debug symbols and freeglut doesn't or vice versa. You only need a debug version of the library when you're "debugging the library". -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Martin P. <li...@ma...> - 2012-05-25 13:15:09
|
Hi Geoff, On 25/05/2012 13:15, Geoff McLane wrote: > (b) Next thing was to kill the .DEF file > addition and generation... I note you already do > this when building WIN64, so why keep it for > WIN32... > > Well ok, I created an OPTION > option(ADD_WIN32_DEF "Generate and link with a > DEF file" OFF) > in case 'someone' wants it ON, then twice > IF(MSVC AND ADD_WIN32_DEF AND NOT CMAKE_CL_64) The def file is used on the win32 build so that the functions are exported without decorated names. Without the def file the glut functions would be exported with names like "_glutFunction@4" instead of "glutFunction", and thus would not be binary compatible with GLUT for win32. This is not needed for the 64 bit build as there was no 64 bit build of GLUT for win32, and besides, the exported names on Windows x64 do not have decorations anyway. I'm not aware of any elegant way to export undecorated function names from a DLL without the use of a module definition, but if there is then it would probably be preferable to the current way--it's easy to forget to update the def file when new functions are added to freeglut. Regards, Martin |
From: Geoff M. <ub...@ge...> - 2012-05-25 14:21:58
|
On Fri, 2012-05-25 at 15:22 +0300, John Tsiombikas wrote: > On Fri, May 25, 2012 at 09:29:45AM +0800, Diederick C. Niehorster wrote: > > On Mon, May 21, 2012 at 9:37 PM, John Tsiombikas <nu...@me...> wrote: > > > On Mon, May 21, 2012 at 06:13:56PM +0800, Diederick C. Niehorster wrote: > > >> > > >> Also, do we want to add a d suffix for all debug builds on all > > >> platforms? The attached path is doing it only for MSVC/windows. > > > > > > Speaking for all UNIX platforms: absolutely not :) > > > > Why is this a windows+MSVC only thing? Wouldn't it be generally useful > > for the same reasons? > > Because windows is the only platform in the universe braindamaged enough > to have 4 different mutually incompatible versions of the standard C > library: single-threaded, single-threaded DLL, multi-threaded, > multi-threaded DLL, single-threaded debug, single-threaded debug DLL, > multi-threaded debug, multi-threaded debug DLL. > Did I say 4? I meant 8... madness. > > So it tends to force you to use "debug" libraries with "debug" > builds, and "release" libraries with "release" builds, just to make sure > you're not using 2-3 different standard libraries in the same > application... > > On other systems the only difference between a "debug" and "non-debug" > versions of a library is basically the presence of debugging symbols in > it, for source-level debuggers. So it doesn't matter in the least if > your application has debug symbols and freeglut doesn't or vice versa. > You only need a debug version of the library when you're "debugging the > library". > Hi John, Thanks for your input... I am truly sorry you think the most MAJOR OS in the world, namely Windows - and by that I mean used by MORE people around the world every day, than any other - is 'braindamaged' ;=)) Perhaps it is just that when you have lived with the MS 'madness', as you call it, for as long as I have you get used to it... or at least accept the status quo without squealing and complaining ;=)) I am sure anyone of us could cast aspersions at ANY OS, ANY TIME - they all have their faults, peculiarities, quirks, what ever you want to call them... Yes, windows does have two forms - Debug and Release - and quite often they can NOT be mixed. And be thankful that you only have one in unix - just with or without the debug symbol sections. But the Debug versions of programs and libraries do a lot, a BIG LOT more than just giving debug symbols... (a) the memory allocation like 'new' uses a debug_new which - (i) allocates more that the requested block and fills the lead up and tail with a specific pattern to be able to watch for under and over runs of the allocation. (ii) fills the memory with another pattern to check if you are specifically initializing it,, and NOT always expecting it to be zero... (iii) keeps stats on allocations, frees, etc, and can give a big debug report if request... especially memory leaks... (b) all functions have (i) an enhanced lead in and exit code - prologue and epilogue - where the variables allocated on the local stack are filled with a pattern, again to check if you are initializing all of them before use... (ii) performs stack checking on exit... catching things like mismatched calling like say '__cdecl' versus 'stdcall', etc (c) In Debug an 'assert()' is enabled with code, while it results in no code if 'NDEBUG' is declared as in the release... (d) and more... NONE of which can be done by just including or not including the debug symbol sections. And yes, in Windows we can choose to import common functions, like the simple strlen() either from another DLL, that is another shared library, the DLL version, or /MD, or can immediately import the function modules from a static library, /ML. And there are reasons why you might choose one over the other, depending on circumstances... So that gives us 4, or 2 x 2 - /MD /MDd and /MT /MTd - no one in their right mind uses the single threaded versions these days, even of you are not using any 'thread' coding... cmake defaults to generating at least /MD and /MDd And yes, in my project that uses freeglut most of the time I do NOT really 'need' the Debug version of freeglut, since as you point out I should only be interested in debugging my application... But as I am sure you are aware, often such 'bugs' are an interaction between my project and other 3rd party libraries, so it is good to be able to trace into freeglut now and then, to see and understand, at source line view level, how my API call is being handled, stacked parameter extracted, converted, etc... This leads to a better understanding all around, something you would NOT see unless you are using a GUI/windows debugger, that shows the actual source lines as you trace through... that has F10 to skip tracing into a functions, or F8 to trace into the call... Without the Debug version of say freeglut, then F8 is disabled, and if you force a trace into a freeglut call, you only see assembler code... which gives you nothing... even for me who wrote assembler in my youth ;=)) Anyway, each person is free to choose what OS they work in, and understand, and I can only hope there is some tolerance of other peoples choices. By all means tell us the 'problems' in the OS of your choice, and less about that which you do not work in on a daily basis... I am sorry for this rant ;=() It is just that over the many years, I do get a little tired of Windows/MS 'bashing' ;=)) especially by those not working all the time in windows... it just does not seem to help the discussion in any way... Regards, Geoff. |
From: John T. <nu...@me...> - 2012-05-25 16:31:37
|
On Fri, May 25, 2012 at 04:21:46PM +0200, Geoff McLane wrote: > I am sorry for this rant ;=() > > It is just that over the many years, I do get a > little tired of Windows/MS 'bashing' ;=)) especially > by those not working all the time in windows... > it just does not seem to help the discussion in > any way... I will not continue discussing the merits and shortcomings of windows because I don't think it's the right place to hold such discussions, and mostly because I do not find that topic interesting. I only wanted to refute your claim that I don't know what I'm talking about. My criticisms and disdain for windows come from a *long* experience programming for that environment, and my choice of operating system is not random at all. -- John Tsiombikas http://nuclear.mutantstargoat.com/ |
From: Geoff M. <ub...@ge...> - 2012-05-25 15:08:07
|
On Fri, 2012-05-25 at 14:14 +0100, Martin Payne wrote: > Hi Geoff, > > On 25/05/2012 13:15, Geoff McLane wrote: > > (b) Next thing was to kill the .DEF file > > addition and generation... I note you already do > > this when building WIN64, so why keep it for > > WIN32... > > > > Well ok, I created an OPTION > > option(ADD_WIN32_DEF "Generate and link with a > > DEF file" OFF) > > in case 'someone' wants it ON, then twice > > IF(MSVC AND ADD_WIN32_DEF AND NOT CMAKE_CL_64) > > The def file is used on the win32 build so that the functions are > exported without decorated names. Without the def file the glut > functions would be exported with names like "_glutFunction@4" instead of > "glutFunction", and thus would not be binary compatible with GLUT for > win32. This is not needed for the 64 bit build as there was no 64 bit > build of GLUT for win32, and besides, the exported names on Windows x64 > do not have decorations anyway. > > I'm not aware of any elegant way to export undecorated function names > from a DLL without the use of a module definition, but if there is then > it would probably be preferable to the current way--it's easy to forget > to update the def file when new functions are added to freeglut. > > Regards, > Martin Hi Martin, In simple terms NO. As I explained you do NOT need the DEF file to get 'undecorated' names. That is done by the external "C" declaration around a header. While "_glutFunction@4" is a form of decoration, it only says its a 'stdcall', (pascal convention) that looks after dropping 4 levels of stack before returning... As opposed to the default __cdecl where it is the caller that must look after the stack... Oh, and the pascal convention also reverses the order of the parameters pushed onto the stack... In C++ a decorated names will give indications of what is returned by the function, and what parameters are passed to the function - And it happens in both WIN32 and WIN64... So a simple function like void foo(int i, char c) becomes a big mess, something like ?foo@@YAXHD@Z ;=)) It is also called name mangling, and is used in C++ to differentiate between over loaded function like void foo(int i, char c); void foo(char c) { foo( 0, c ); } And name mangling is NOT cross-compiler compatible. That is gcc, mingw, MS cl, etc... each can have their own different form of 'mangling' ;=(( So I repeat again, the DEF file generation is NOT required, but as I wrote, I implemented it as an OPTION so you could turn it back on if really desired. And for sure when the DEF is used to create an undecorated 'alias', then the resultant library will hold BOTH - _glutFunction@4 and _glutFunction - both pointing to the same function... But I think it should be OFF by default. And as mentioned I had no problems when I compiled and linked the 20 or so demos using NO DEF file, in a WIN32 build. Regards, Geoff. |