From: Sisyphus <sis...@op...> - 2009-10-27 10:43:24
|
Hi, Does anyone here have comprehensive instructions for buidling freeglut-2.6.0-rc1 (or even 2.4.0) with the MinGW port of gcc on Win32 ? I've had good success with building a number of libraries for native win32 with this compiler by first running ./configure in the msys shell ... but not freeglut. With 2.6.0-rc1, irrespective of whether I run './configure --disable-static --enable-shared' or './configure --disable-shared --enable-static', the failure is the same. The 'configure' step runs fine, and make succeeds to the extent that a 'libglut.a' is created in src/.libs (along with libglut.la and libglut.lai) but I strike trouble as soon as 'make' tries to create CallbackMaker.exe. Here's a snipped output of make: ###################################### make all-recursive make[1]: Entering directory `/c/_32/comp/freeglut-2.6.0' Making all in src make[2]: Entering directory `/c/_32/comp/freeglut-2.6.0/src' /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I../include -DFREEGLUT_EXPORTS -g -O2 -Wall -pedantic -MT libglut_la-freeglut_callbacks.lo -MD -MP -MF .deps/libglut_la-freeglut_callbacks.Tpo -c -o libglut_la-freeglut_callbacks.lo `test -f 'freeglut_callbacks.c' || echo './'`freeglut_callbacks.c gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DFREEGLUT_EXPORTS -g -O2 -Wall -pedantic -MT libglut_la-freeglut_callbacks.lo -MD -MP -MF .deps/libglut_la-freeglut_callbacks.Tpo -c freeglut_callbacks.c -o libglut_la-freeglut_callbacks.o mv -f .deps/libglut_la-freeglut_callbacks.Tpo .deps/libglut_la-freeglut_callbacks.Plo [snip] /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I../include -DFREEGLUT_EXPORTS -g -O2 -Wall -pedantic -MT libglut_la-freeglut_window.lo -MD -MP -MF .deps/libglut_la-freeglut_window.Tpo -c -o libglut_la-freeglut_window.lo `test -f 'freeglut_window.c' || echo './'`freeglut_window.c gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DFREEGLUT_EXPORTS -g -O2 -Wall -pedantic -MT libglut_la-freeglut_window.lo -MD -MP -MF .deps/libglut_la-freeglut_window.Tpo -c freeglut_window.c -o libglut_la-freeglut_window.o mv -f .deps/libglut_la-freeglut_window.Tpo .deps/libglut_la-freeglut_window.Plo /bin/sh ../libtool --tag=CC --mode=link gcc -DFREEGLUT_EXPORTS -g -O2 -Wall -pedantic -no-undefined -o libglut.la -rpath /usr/local/lib libglut_la-freeglut_callbacks.lo libglut_la-freeglut_cursor.lo libglut_la-freeglut_display.lo libglut_la-freeglut_ext.lo libglut_la-freeglut_font.lo libglut_la-freeglut_glutfont_definitions.lo libglut_la-freeglut_font_data.lo libglut_la-freeglut_stroke_roman.lo libglut_la-freeglut_stroke_mono_roman.lo libglut_la-freeglut_gamemode.lo libglut_la-freeglut_geometry.lo libglut_la-freeglut_init.lo libglut_la-freeglut_input_devices.lo libglut_la-freeglut_joystick.lo libglut_la-freeglut_main.lo libglut_la-freeglut_menu.lo libglut_la-freeglut_misc.lo libglut_la-freeglut_overlay.lo libglut_la-freeglut_state.lo libglut_la-freeglut_structure.lo libglut_la-freeglut_teapot.lo libglut_la-freeglut_videoresize.lo ibglut_la-freeglut_window.lo -lm -lopengl32 -lgdi32 -lwinmm mkdir .libs ar cru .libs/libglut.a libglut_la-freeglut_callbacks.o libglut_la-freeglut_cursor.o libglut_la-freeglut_display.o libglut_la-freeglut_ext.o libglut_la-freeglut_font.o libglut_la-freeglut_glutfont_definitions.o libglut_la-freeglut_font_data.o libglut_la-freeglut_stroke_roman.o libglut_la-freeglut_stroke_mono_roman.o libglut_la-freeglut_gamemode.o libglut_la-freeglut_geometry.o libglut_la-freeglut_init.o libglut_la-freeglut_input_devices.o libglut_la-freeglut_joystick.o libglut_la-freeglut_main.o libglut_la-freeglut_menu.o libglut_la-freeglut_misc.o libglut_la-freeglut_overlay.o libglut_la-freeglut_state.o libglut_la-freeglut_structure.o libglut_la-freeglut_teapot.o libglut_la-freeglut_videoresize.o libglut_la-freeglut_window.o ranlib .libs/libglut.a creating libglut.la (cd .libs && rm -f libglut.la && cp -p ../libglut.la libglut.la) make[2]: Leaving directory `/c/_32/comp/freeglut-2.6.0/src' Making all in include make[2]: Entering directory `/c/_32/comp/freeglut-2.6.0/include' Making all in GL make[3]: Entering directory `/c/_32/comp/freeglut-2.6.0/include/GL' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/c/_32/comp/freeglut-2.6.0/include/GL' make[3]: Entering directory `/c/_32/comp/freeglut-2.6.0/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/c/_32/comp/freeglut-2.6.0/include' make[2]: Leaving directory `/c/_32/comp/freeglut-2.6.0/include' Making all in progs make[2]: Entering directory `/c/_32/comp/freeglut-2.6.0/progs' Making all in demos make[3]: Entering directory `/c/_32/comp/freeglut-2.6.0/progs/demos' Making all in CallbackMaker make[4]: Entering directory `/c/_32/comp/freeglut-2.6.0/progs/demos/CallbackMaker' gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include -g -O2 -Wall -pedantic -MT CallbackMaker-CallbackMaker.o -MD -MP -MF .deps/CallbackMaker-CallbackMaker.Tpo -c -o CallbackMaker-CallbackMaker.o `test -f 'CallbackMaker.c' || echo './'`CallbackMaker.c mv -f .deps/CallbackMaker-CallbackMaker.Tpo .deps/CallbackMaker-CallbackMaker.Po /bin/sh ../../../libtool --tag=CC --mode=link gcc -I../../../include -g -O2 -Wall -pedantic -export-dynamic ../../../src/libglut.la -o CallbackMaker.exe CallbackMaker-CallbackMaker.o mkdir .libs gcc -I../../../include -g -O2 -Wall -pedantic -o CallbackMaker.exe CallbackMaker-CallbackMaker.o -Wl,--export-dynamic ../../../src/.libs/libglut.a -lopengl32 -lgdi32 -lwinmm CallbackMaker-CallbackMaker.o: In function `bitmapPrintf': c:/_32/comp/freeglut-2.6.0/progs/demos/CallbackMaker/CallbackMaker.c:46: undefined reference to `_imp__glutBitmapString@8' CallbackMaker-CallbackMaker.o: In function `Display': c:/_32/comp/freeglut-2.6.0/progs/demos/CallbackMaker/CallbackMaker.c:53: undefined reference to `_imp__glutGetWindow@0' [snip many more similar errors] c:/_32/comp/freeglut-2.6.0/progs/demos/CallbackMaker/CallbackMaker.c:531: undefined reference to `_imp__glutMainLoop@0' collect2: ld returned 1 exit status make[4]: *** [CallbackMaker.exe] Error 1 make[4]: Leaving directory `/c/_32/comp/freeglut-2.6.0/progs/demos/CallbackMaker' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/c/_32/comp/freeglut-2.6.0/progs/demos' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/_32/comp/freeglut-2.6.0/progs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/_32/comp/freeglut-2.6.0' make: *** [all] Error 2 ###################################### As I said above, the errors are the same irrespective of whether I've asked for a static lib or a dynamic lib ... and no dll is built in src/.libs when I ask for a dynamic build. Having successfully constructed all of the object files, is there a command(s) I can then run to create the freeglut dll ? Cheers, Rob |
From: Martin P. <li...@ma...> - 2009-10-27 21:28:35
|
Sisyphus wrote: > Hi, > Does anyone here have comprehensive instructions for buidling > freeglut-2.6.0-rc1 (or even 2.4.0) with the MinGW port of gcc on Win32 ? <snip> Hi Rob, No comprehensive instructions that I'm aware of, but I can say that I've had success building both freeglut 2.4.0 and 2.6.0 RC1 with native MinGW (I have 2.4.0 binaries online at http://www.transmissionzero.co.uk/software/freeglut-devel/). I didn't use the configure script, rather I built my own Makefile. The static library is quite easy to build. Just define "FREEGLUT_STATIC" when compiling all of the object files, then do an "ar r libfreeglut_static.a [object files]" on the object files, and then "ranlib libfreeglut_static.a". The freeglut DLL is also quite easy to build. Just define "FREEGLUT_EXPORTS" when compiling all of the object files, and then a "gcc -o freeglut.dll [object files] -s -shared -lopengl32 -lgdi32 -lwinmm -Wl,--kill-at" (the "--kill-at" being to make it more binary compatible with Nate's GLUT for Win32 package, but slightly complicating the building of the import library). For the import library you need to create a module definition file containing the functions with their stdcall decorations, i.e. "glutAddMenuEntry@8". Then just run "dlltool -d [def file.def] -l libfreeglut.a --kill-at". I hope this helps. Let me know if you want a copy of the Makefile, def file, etc., and I'll send them over to you. Regards, Martin |
From: Sisyphus <sis...@op...> - 2009-10-28 02:27:28
|
----- Original Message ----- From: "Martin Payne" <li...@ma...> > Hi Rob, > > No comprehensive instructions that I'm aware of, but I can say that I've > had success building both freeglut 2.4.0 and 2.6.0 RC1 with native MinGW > (I have 2.4.0 binaries online at > http://www.transmissionzero.co.uk/software/freeglut-devel/). I didn't > use the configure script, rather I built my own Makefile. > > The static library is quite easy to build. Just define "FREEGLUT_STATIC" > when compiling all of the object files, then do an "ar r > libfreeglut_static.a [object files]" on the object files, and then > "ranlib libfreeglut_static.a". I now find I can build a static lib ok in the msys shell with: ./configure --disable-shared --enable-static CFLAGS=-DFREEGLUT_STATIC > > The freeglut DLL is also quite easy to build. Just define > "FREEGLUT_EXPORTS" when compiling all of the object files, and then a > "gcc -o freeglut.dll [object files] -s -shared -lopengl32 -lgdi32 > -lwinmm -Wl,--kill-at" (the "--kill-at" being to make it more binary > compatible with Nate's GLUT for Win32 package, but slightly complicating > the building of the import library). > > For the import library you need to create a module definition file > containing the functions with their stdcall decorations, i.e. > "glutAddMenuEntry@8". Then just run "dlltool -d [def file.def] -l > libfreeglut.a --kill-at". > > I hope this helps. Let me know if you want a copy of the Makefile, def > file, etc., and I'll send them over to you. Thanks very much for all of that. I'd be delighted if you could send me the Makefile and def file. (I gather the freeglutdll.def that I find in the src folder is inadequate ?) I'm actually wanting to build the dll with mingw64. I can get the static build ok with it, too - but attempted dll builds (with both 32 and 64 bit compilers) always revert to a static build with a rather long-winded message about not being able to find a libgdi32 dll and libwinmm dll. I'm just now thinking about a way to get around that problem (which I'll try later), but if you could send me those 2 files that would be fantastic - I would then at least have something that works.. (If you have them for 2.6.0-rc1, that alone would be sufficient. If you don't have them for 2.6.0-rc1, 2.4.0 would be fine.) Thanks again for taking the time to provide such detailed information. Cheers, Rob |
From: Martin P. <li...@ma...> - 2009-10-28 21:15:50
|
Hi Rob, Sisyphus wrote: > Thanks very much for all of that. > I'd be delighted if you could send me the Makefile and def file. (I gather > the freeglutdll.def that I find in the src folder is inadequate ?) > No probs. Sure, I'll send that to you off-list in a moment. The "freeglutdll.def" in the src folder is fine for building the DLL, but not for the import library because the stdcall function decorations are needed for that. Without those and / or the "--kill-at" on the dlltool command line, you'll either get problems linking freeglut apps, or they will link fine but fail at runtime. I followed a good guide from a site on the now defunct GeoCities, but it can still be found at "http://web.archive.org/web/20071015090216/http://www.geocities.com/yongweiwu/stdcall.htm". > I'm actually wanting to build the dll with mingw64. I can get the static > build ok with it, too - but attempted dll builds (with both 32 and 64 bit > compilers) always revert to a static build with a rather long-winded message > about not being able to find a libgdi32 dll and libwinmm dll. I'd be interested to know how you get on with this. I received my copy of Windows 7 in the post last week, and I've built a 64 bit MSVC version of freeglut and compiled some test apps with great success. I've not had a chance to look at the 64 bit MinGW yet though. Perhaps I'll do that once I've got the hang of the new Windows 7 taskbar... :-) Regards, Martin |
From: Clive M. <Cli...@ms...> - 2009-10-29 08:06:38
|
-------------------------------------------------- From: "Martin Payne" <li...@ma...> Sent: Tuesday, October 27, 2009 2:15 PM To: "FreeGLUT developers list" <fre...@li...> Subject: Re: [Freeglut-developer] Buidling freeglut-2.6.0-rc1 with mingw32 > Sisyphus wrote: >> Hi, >> Does anyone here have comprehensive instructions for buidling >> freeglut-2.6.0-rc1 (or even 2.4.0) with the MinGW port of gcc on Win32 ? > <snip> > > Hi Rob, > > No comprehensive instructions that I'm aware of, but I can say that I've > had success building both freeglut 2.4.0 and 2.6.0 RC1 with native MinGW > (I have 2.4.0 binaries online at > http://www.transmissionzero.co.uk/software/freeglut-devel/). I didn't > use the configure script, rather I built my own Makefile. > > The static library is quite easy to build. Just define "FREEGLUT_STATIC" > when compiling all of the object files, then do an "ar r > libfreeglut_static.a [object files]" on the object files, and then > "ranlib libfreeglut_static.a". > > The freeglut DLL is also quite easy to build. Just define > "FREEGLUT_EXPORTS" when compiling all of the object files, and then a > "gcc -o freeglut.dll [object files] -s -shared -lopengl32 -lgdi32 > -lwinmm -Wl,--kill-at" (the "--kill-at" being to make it more binary > compatible with Nate's GLUT for Win32 package, but slightly complicating > the building of the import library). > > For the import library you need to create a module definition file > containing the functions with their stdcall decorations, i.e. > "glutAddMenuEntry@8". Then just run "dlltool -d [def file.def] -l > libfreeglut.a --kill-at". > > I hope this helps. Let me know if you want a copy of the Makefile, def > file, etc., and I'll send them over to you. > > Regards, > Martin > > I'd like to make a plea NOT to make things "binary compatible" with Nate's GLUT. I spent a good deal of time trying to get an appropriate import library to work with MinGW gcc. There is a "help" page on MinGW that is there explicitly to assist folks link to Nate's GLUT Win32 DLL (it's all very confusing). I would recommend that a DLL be built that can simply be placed on the gcc command line for dynamic linkage. Then NO import library is needed at all, and all of the kill--at and linkage decoration issues go away too. I realize that it's not freeglut policy to release binaries, but if you are going to make something "more binary compatible" you have already taken the first step along the road (to 'hell' you might argue!) I'd make a pitch to release a Win32 DLL that works with MinGW and MSC VC compilers. That should cover 90% of users. The remainder is probably 5% Linux and 4% Mac OS and then others... Clive. |
From: Martin P. <li...@ma...> - 2009-10-31 10:58:24
|
Hi Clive, Clive McCarthy wrote: > I'd like to make a plea NOT to make things "binary compatible" with Nate's > GLUT. I spent a good deal of time trying to get an appropriate import > library to work with MinGW gcc. There is a "help" page on MinGW that is > there explicitly to assist folks link to Nate's GLUT Win32 DLL (it's all > very confusing). I would recommend that a DLL be built that can simply be > placed on the gcc command line for dynamic linkage. Then NO import library > is needed at all, and all of the kill--at and linkage decoration issues go > away too. > <snip> The only problem I've seen with Nate's package and MinGW is that MinGW is distributed with an older import library, and without a GLUT header. People add a newer header to their MinGW install which contains some new function declarations (the "atexit" hack stuff), keeping the older import library in the lib path, and the linker fails with a load of unresolved symbols. I don't think this should be considered an issue with GLUT, rather an issue with users not obtaining an up to date import library suitable for use with MinGW (or perhaps an issue that MinGW contains an import library with no matching header). I'm not really sure why a DLL with undecorated function exports would cause problems. It's consistent with other Windows DLLs, and in addition to binary compatibility with Nate Robins' DLL, it ensures binary compatibility between MinGW builds and MSVC builds. All that is needed is to have the appropriate import library in the lib path, and for that import library to be specified on the linker command line. > I'd make a pitch to release a Win32 DLL that works with MinGW and MSC VC > compilers. That should cover 90% of users. The remainder is probably 5% > Linux and 4% Mac OS and then others... This I have already done. I built freeglut from source with MSVC using the module definition file included in the source distribution. I then built the MinGW version using the techniques described in my original reply to ensure that the MinGW DLL is binary compatible with the MSVC DLL. It's possible to deploy applications using either of the two DLLs, depending on which is preferred. Regards, Martin |
From: Clive M. <Cli...@ms...> - 2009-10-31 15:22:49
|
-------------------------------------------------- From: "Martin Payne" <li...@ma...> Sent: Saturday, October 31, 2009 3:45 AM To: "FreeGLUT developers list" <fre...@li...> Subject: Re: [Freeglut-developer] Buidling freeglut-2.6.0-rc1 with mingw32 > Hi Clive, > > Clive McCarthy wrote: >> I'd like to make a plea NOT to make things "binary compatible" with >> Nate's >> GLUT. I spent a good deal of time trying to get an appropriate import >> library to work with MinGW gcc. There is a "help" page on MinGW that is >> there explicitly to assist folks link to Nate's GLUT Win32 DLL (it's all >> very confusing). I would recommend that a DLL be built that can simply be >> placed on the gcc command line for dynamic linkage. Then NO import >> library >> is needed at all, and all of the kill--at and linkage decoration issues >> go >> away too. >> > <snip> > > The only problem I've seen with Nate's package and MinGW is that MinGW > is distributed with an older import library, and without a GLUT header. > People add a newer header to their MinGW install which contains some new > function declarations (the "atexit" hack stuff), keeping the older > import library in the lib path, and the linker fails with a load of > unresolved symbols. I don't think this should be considered an issue > with GLUT, rather an issue with users not obtaining an up to date import > library suitable for use with MinGW (or perhaps an issue that MinGW > contains an import library with no matching header). > > I'm not really sure why a DLL with undecorated function exports would > cause problems. It's consistent with other Windows DLLs, and in addition > to binary compatibility with Nate Robins' DLL, it ensures binary > compatibility between MinGW builds and MSVC builds. All that is needed > is to have the appropriate import library in the lib path, and for that > import library to be specified on the linker command line. > >> I'd make a pitch to release a Win32 DLL that works with MinGW and MSC VC >> compilers. That should cover 90% of users. The remainder is probably 5% >> Linux and 4% Mac OS and then others... > > This I have already done. I built freeglut from source with MSVC using > the module definition file included in the source distribution. I then > built the MinGW version using the techniques described in my original > reply to ensure that the MinGW DLL is binary compatible with the MSVC > DLL. It's possible to deploy applications using either of the two DLLs, > depending on which is preferred. > > Regards, > Martin Martin, It was probably my inexperience with gcc but it took me a while to resolve the issues. I had a well established system using GLUT obtained from Nate Robins' website using the DLL I obtained there. I built an import library to link to an (old) Borland compiler and all was well. I tried the same thing with freeglut and gcc and had lots of link errors because of the decorations or their absence. I am told that gcc does not need ANY import library: one just places a reference to the DLL on the command line and gcc will link directly with the DLL itself. I haven't tried this with the freeglut.dll but it worked well with the freetype.dll I am using. I believe the MinGW folks don't release a glut.h because it is NOT part of Windows. Only gl.h and glu.h are released by them uniformly with Windows itself. Like most people, I suspect, I'm simply too lazy to build freeglut from the source. I finally scoured the web for a ready-made freeglut.dll and installed that along with freeglut.h, freeglut_std.h and freeglut_ext.h -- not a very hygienic approach, I admit. So if you already have the Windows DLL ready built, making it available on SourceForge along with the headers would make things _very_ simple for lazy MinGW gcc users like me. I presume the same is true for MSVC users. Clive. |
From: Martin P. <li...@ma...> - 2009-10-31 20:08:15
|
Hi Clive, Clive McCarthy wrote: > Martin, > It was probably my inexperience with gcc but it took me a while to resolve > the issues. I had a well established system using GLUT obtained from Nate > Robins' website using the DLL I obtained there. I built an import library to > link to an (old) Borland compiler and all was well. I tried the same thing > with freeglut and gcc and had lots of link errors because of the decorations > or their absence. I am told that gcc does not need ANY import library: one > just places a reference to the DLL on the command line and gcc will link > directly with the DLL itself. I haven't tried this with the freeglut.dll but > it worked well with the freetype.dll I am using. > <snip> With MinGW, the ability to reference the DLL on the linker command line depends on which compiler was used to build the DLL, and the calling convention of the exported functions. For example if the DLL was built with MSVC and the functions are declared "__cdecl", then you can just place the DLL name on the gcc command line. If the DLL was built with MSVC and the functions are declared "__stdcall", it won't work with MinGW without an import library because MSVC and MinGW use different decorations for exported stdcall functions. > Like most people, I suspect, I'm simply too lazy to build freeglut from the > source. I finally scoured the web for a ready-made freeglut.dll and > installed that along with freeglut.h, freeglut_std.h and freeglut_ext.h -- > not a very hygienic approach, I admit. So if you already have the Windows > DLL ready built, making it available on SourceForge along with the headers > would make things _very_ simple for lazy MinGW gcc users like me. I wrote a tutorial about using GLUT with MinGW a few years ago, and recently added freeglut to it as well. The tutorial is at "http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/", and the freeglut MinGW import library, static library, headers and DLL can be downloaded from there. Maybe the freeglut guys would like me to provide a link to have my freeglut MSVC and MinGW packages listed under "Prepackaged Releases"? Regards, Martin |
From: Clive M. <Cli...@ms...> - 2009-11-01 09:12:13
|
-------------------------------------------------- From: "Martin Payne" <li...@ma...> Sent: Saturday, October 31, 2009 12:08 PM To: "FreeGLUT developers list" <fre...@li...> Subject: Re: [Freeglut-developer] Buidling freeglut-2.6.0-rc1 with mingw32 > Hi Clive, > > Clive McCarthy wrote: >> Martin, >> It was probably my inexperience with gcc but it took me a while to >> resolve >> the issues. I had a well established system using GLUT obtained from Nate >> Robins' website using the DLL I obtained there. I built an import library >> to >> link to an (old) Borland compiler and all was well. I tried the same >> thing >> with freeglut and gcc and had lots of link errors because of the >> decorations >> or their absence. I am told that gcc does not need ANY import library: >> one >> just places a reference to the DLL on the command line and gcc will link >> directly with the DLL itself. I haven't tried this with the freeglut.dll >> but >> it worked well with the freetype.dll I am using. >> > <snip> > > With MinGW, the ability to reference the DLL on the linker command line > depends on which compiler was used to build the DLL, and the calling > convention of the exported functions. For example if the DLL was built > with MSVC and the functions are declared "__cdecl", then you can just > place the DLL name on the gcc command line. If the DLL was built with > MSVC and the functions are declared "__stdcall", it won't work with > MinGW without an import library because MSVC and MinGW use different > decorations for exported stdcall functions. > >> Like most people, I suspect, I'm simply too lazy to build freeglut from >> the >> source. I finally scoured the web for a ready-made freeglut.dll and >> installed that along with freeglut.h, freeglut_std.h and >> freeglut_ext.h -- >> not a very hygienic approach, I admit. So if you already have the Windows >> DLL ready built, making it available on SourceForge along with the >> headers >> would make things _very_ simple for lazy MinGW gcc users like me. > > I wrote a tutorial about using GLUT with MinGW a few years ago, and > recently added freeglut to it as well. The tutorial is at > "http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/", > and the freeglut MinGW import library, static library, headers and DLL > can be downloaded from there. Maybe the freeglut guys would like me to > provide a link to have my freeglut MSVC and MinGW packages listed under > "Prepackaged Releases"? > > Regards, > Martin > Martin, That's great ! It would be a great boon to lazy, inexperienced people like me. I do hope you can persuade the freeglut guys to add your URL to the pre-packaged releases list on the main page. It is clear (to me) that the Nate Robins' pre-packaging helped with the popularity of GLUT and it is a shame that freeglut hasn't got the same facility. Clive. |
From: Clive M. <Cli...@ms...> - 2009-11-01 09:56:35
|
-------------------------------------------------- From: "Martin Payne" <li...@ma...> Sent: Saturday, October 31, 2009 12:08 PM To: "FreeGLUT developers list" <fre...@li...> Subject: Re: [Freeglut-developer] Buidling freeglut-2.6.0-rc1 with mingw32 > Hi Clive, > > Clive McCarthy wrote: >> Martin, >> It was probably my inexperience with gcc but it took me a while to >> resolve >> the issues. I had a well established system using GLUT obtained from Nate >> Robins' website using the DLL I obtained there. I built an import library >> to >> link to an (old) Borland compiler and all was well. I tried the same >> thing >> with freeglut and gcc and had lots of link errors because of the >> decorations >> or their absence. I am told that gcc does not need ANY import library: >> one >> just places a reference to the DLL on the command line and gcc will link >> directly with the DLL itself. I haven't tried this with the freeglut.dll >> but >> it worked well with the freetype.dll I am using. >> > <snip> > > With MinGW, the ability to reference the DLL on the linker command line > depends on which compiler was used to build the DLL, and the calling > convention of the exported functions. For example if the DLL was built > with MSVC and the functions are declared "__cdecl", then you can just > place the DLL name on the gcc command line. If the DLL was built with > MSVC and the functions are declared "__stdcall", it won't work with > MinGW without an import library because MSVC and MinGW use different > decorations for exported stdcall functions. > >> Like most people, I suspect, I'm simply too lazy to build freeglut from >> the >> source. I finally scoured the web for a ready-made freeglut.dll and >> installed that along with freeglut.h, freeglut_std.h and >> freeglut_ext.h -- >> not a very hygienic approach, I admit. So if you already have the Windows >> DLL ready built, making it available on SourceForge along with the >> headers >> would make things _very_ simple for lazy MinGW gcc users like me. > > I wrote a tutorial about using GLUT with MinGW a few years ago, and > recently added freeglut to it as well. The tutorial is at > "http://www.transmissionzero.co.uk/computing/using-glut-with-mingw/", > and the freeglut MinGW import library, static library, headers and DLL > can be downloaded from there. Maybe the freeglut guys would like me to > provide a link to have my freeglut MSVC and MinGW packages listed under > "Prepackaged Releases"? > > Regards, > Martin > Martin, It just occurred to me that you might put an external link on the Wikipedia entry for freeglut. That way people researching the status of GLUT and freeglut would have a sense that freeglut is alive and well. I posted some queries on GameDev and OpenGL sites but obtained responses that commonly considered freeglut to be a dead project. This is a pity because so many people starting with OpenGL will use GLUT as a foundation since most books, on the subject OpenGL, tacitly use GLUT as if it were an intrinsic part of OpenGL. It seems wasteful of the work people have put into freeglut not to make is more readily accessible. Clive. |
From: John F. F. <joh...@cy...> - 2009-12-02 12:25:07
|
Has all of this been recorded in the "README.cygwin_mingw" file? If not, would it be possible to add it there? - John At 03:15 PM 10/27/2009, you wrote: >Sisyphus wrote: > > Hi, > > Does anyone here have comprehensive instructions for buidling > > freeglut-2.6.0-rc1 (or even 2.4.0) with the MinGW port of gcc on Win32 ? ><snip> > >Hi Rob, > >No comprehensive instructions that I'm aware of, but I can say that I've >had success building both freeglut 2.4.0 and 2.6.0 RC1 with native MinGW >(I have 2.4.0 binaries online at >http://www.transmissionzero.co.uk/software/freeglut-devel/). I didn't >use the configure script, rather I built my own Makefile. > >The static library is quite easy to build. Just define "FREEGLUT_STATIC" >when compiling all of the object files, then do an "ar r >libfreeglut_static.a [object files]" on the object files, and then >"ranlib libfreeglut_static.a". > >The freeglut DLL is also quite easy to build. Just define >"FREEGLUT_EXPORTS" when compiling all of the object files, and then a >"gcc -o freeglut.dll [object files] -s -shared -lopengl32 -lgdi32 >-lwinmm -Wl,--kill-at" (the "--kill-at" being to make it more binary >compatible with Nate's GLUT for Win32 package, but slightly complicating >the building of the import library). > >For the import library you need to create a module definition file >containing the functions with their stdcall decorations, i.e. >"glutAddMenuEntry@8". Then just run "dlltool -d [def file.def] -l >libfreeglut.a --kill-at". > >I hope this helps. Let me know if you want a copy of the Makefile, def >file, etc., and I'll send them over to you. > >Regards, >Martin > >------------------------------------------------------------------------------ >Come build with us! The BlackBerry(R) Developer Conference in SF, CA >is the only developer event you need to attend this year. Jumpstart your >developing skills, take BlackBerry mobile applications to market and stay >ahead of the curve. Join us from November 9 - 12, 2009. Register now! >http://p.sf.net/sfu/devconference >_______________________________________________ >Freeglut-developer mailing list >Fre...@li... >https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Martin P. <li...@ma...> - 2009-12-03 21:39:46
|
Hi John, John F. Fay wrote: > Has all of this been recorded in the "README.cygwin_mingw" file? If > not, would it be possible to add it there? This thread relates to the native Windows version of MinGW, whereas the readme relates to the Cygwin version of MinGW. I've not tried to build with the Cygwin version of MinGW, but I think it's very different (as far as I can see, it's a configure + make job). Building with the native MinGW is not so straightforward--I created my build by copying the source files and headers to a new directory structure, and creating a custom Makefile and def file. I could adapt them, document it, and submit if it's useful though. Regards, Martin |
From: Clive M. <Cli...@ms...> - 2009-12-03 22:03:39
|
Martin, This explains why I'm having so much difficulty putting together a MinGW build environment for 2.6.0 So it would be useful for me. Clive. -------------------------------------------------- From: "Martin Payne" <li...@ma...> Sent: Thursday, December 03, 2009 1:39 PM To: "FreeGLUT developers list" <fre...@li...> Subject: Re: [Freeglut-developer] Buidling freeglut-2.6.0-rc1 with mingw32 > Hi John, > > John F. Fay wrote: >> Has all of this been recorded in the "README.cygwin_mingw" file? If >> not, would it be possible to add it there? > > This thread relates to the native Windows version of MinGW, whereas the > readme relates to the Cygwin version of MinGW. I've not tried to build > with the Cygwin version of MinGW, but I think it's very different (as > far as I can see, it's a configure + make job). > > Building with the native MinGW is not so straightforward--I created my > build by copying the source files and headers to a new directory > structure, and creating a custom Makefile and def file. I could adapt > them, document it, and submit if it's useful though. > > Regards, > Martin > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Freeglut-developer mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freeglut-developer > |