From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-18 13:58:44
|
Boy, this is what I get for going offline after five and not coming back until the morning. I get to come in late for all the interesting discussions. I think we have two or three things going on here. (1) Should "freeglut" have any "#pragma" preprocessor symbols? I submit that the answer is very much yes: GLUT uses them in Windows as a means for pointing the application to which ".lib" file to use. Unless somebody has another way of doing this without changing the application in any way (by which I mean source code and project file) we will need the "#pragma" to do this. It should be wrapped thoroughly in a "#if" block so that non-MSVC compilers never see it, though. (Should we put it in its own "freeglut_win32_msvc_include.h" file, as Richard said would shield it completely?) (2) The "#pragma message" warning in "freeglut_window.c" simply prints out a warning at compile time. I think we could replace that with one of Richard's "XXX" comments (those are a very good idea, by the way) and not harm anything. (3) Right now there are two primary divisions within "freeglut": TARGET_HOST_UNIX_X11 and TARGET_HOST_WIN32. Within the former we have "__FreeBSD__" and "__NetBSD__" (and possibly others) while within the latter we have "__CYGWIN__" and "CYGWIN32__" and we are talking about adding a few more. It strikes me that these subdivisions are somewhat disorganized. I would like to see some structure here: somewhere in the code (probably at the beginning of "freeglut_internal.h") we should have a list of platforms and compilers supported and which symbols are set to one on which platform and defined for which compiler. John F. Fay joh...@eg... |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-22 15:20:05
|
Nigel, First let me say that your original intent was absolutely on target: the "TARGET_HOST_WIN32" needs to be subdivided into MSVC and other things. We only need to decide how, and then go ahead and implement it. If you have a solution that satisfies you, please put it out and we will most likely use it (or something very close to it). The larger question of pragmas is, as you say, a separate issue but is still something that we should settle. Since the original GLUT used pragmas, I think "freeglut" should go ahead and use them as well. I would NOT, however, use them unless we absolutely have to (and I would categorize the specification of the "freeglut.lib" under Windows/MSVC as absolutely having to). I would also add a comment just before the "pragma" statement saying "If your compiler objects to this directive even though it is supposedly protected from it, then you can do the following" and describe Richard's process of making a "#include" file that contains nothing but the pragma. John F. Fay joh...@eg... -----Original Message----- From: Nigel Stewart and Fiona Smith [mailto:ni...@ni...] Sent: Sunday, December 21, 2003 6:21 AM To: fre...@li... Subject: Re: [Freeglut-developer] #pragma comment (lib, ...) is Visual C++ Specific >>(Should we put it in its own >>"freeglut_win32_msvc_include.h" file, as Richard said would shield it >>completely?) > > I hope that such an extreme measure is not required to protect #pragmas, > though it sounds like it may be. But I think that it covers any technical > objection. Perhaps in theory such an extreme solution can be justified. The original intention of this thread was to simply establish the need for some finer-grained handling than generic Win32 and generic X11. I believe that Visual C++ specific pragmas should be conditional on the Visual C++ compiler, not on the platform being some form of Win32. It is always possible for tools to behave unreasonably for grey areas of the established specifications - common practice tends to prevail. I think moving pragmas into another header file is clumsy, excessive and marginally more maintenance prone. (But either way is fine with me...) Nigel ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Richard R. <sf...@ol...> - 2003-12-22 15:31:08
|
[...] > I would also add a comment just before the "pragma" statement saying > "If your compiler objects to this directive even though it is supposedly > protected from it, then you can do the following" and describe Richard's > process of making a "#include" file that contains nothing but the pragma. If we choose to ignore the issue, I think that we should not advocate that users hack up freeglut distribution files locally. Let them file a bug-report. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-22 16:00:14
|
I must disagree. If a user files a bug report, he would expect some action as a result. The only thing we would do is tell him "We considered the question a long time ago and decided not to support it. If you want 'freeglut' to compile on your system you will have to do this:'" and the resulting file hack will be exactly the same. The only differences will be that (1) we will have wasted his time filing the bug report, (2) we will have wasted our time responding to it, (3) we may not remember this discussion right off (witness the "libGL.la" link question that came up a couple of weeks ago) and may waste a good bit of effort scurrying around figuring out what is happening, and (4) quite possibly he will have decided to take his business elsewhere. John F. Fay joh...@eg... -----Original Message----- From: Richard Rauch [mailto:sf...@ol...] Sent: Monday, December 22, 2003 9:31 AM To: fre...@li... Subject: Re: [Freeglut-developer] #pragma comment (lib, ...) is Visual C++ Specific [...] > I would also add a comment just before the "pragma" statement saying > "If your compiler objects to this directive even though it is supposedly > protected from it, then you can do the following" and describe Richard's > process of making a "#include" file that contains nothing but the pragma. If we choose to ignore the issue, I think that we should not advocate that users hack up freeglut distribution files locally. Let them file a bug-report. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Richard R. <sf...@ol...> - 2003-12-22 19:46:34
|
On Mon, Dec 22, 2003 at 09:59:33AM -0600, Fay John F Contr AAC/WMG wrote: > I must disagree. If a user files a bug report, he would expect some action > as a result. The only thing we would do is tell him "We considered the Yes, and I would expect it to be fixed, too. > question a long time ago and decided not to support it. If you want I was not under the impression that we had agreed to never support this. I thought that people were so repulsed by the fix that we were loosely considering risking bug, but didn't know that people were actually in favor of not fixing it even in the face of it causing real problems for real people trying to use freeglut. > 'freeglut' to compile on your system you will have to do this:'" and the > resulting file hack will be exactly the same. The only differences will be Going one way is a gamble. Going the other is taking out insurance. I lean towards the insurance side: Tuck the #pragma in a separate file, with a comment in that file explaining why it is done. Then forget that it was done and never read the file again. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-22 19:57:58
|
Given that GLUT has used #pragma for a long time, I would be surprised if there were too many cases that they could pose a problem. I will review my changes and propose an approach shortly. Nigel Fay John F Contr AAC/WMG wrote: > I must disagree. If a user files a bug report, he would expect some action > as a result. The only thing we would do is tell him "We considered the > question a long time ago and decided not to support it. If you want > 'freeglut' to compile on your system you will have to do this:'" and the > resulting file hack will be exactly the same. The only differences will be > that (1) we will have wasted his time filing the bug report, (2) we will > have wasted our time responding to it, (3) we may not remember this > discussion right off (witness the "libGL.la" link question that came up a > couple of weeks ago) and may waste a good bit of effort scurrying around > figuring out what is happening, and (4) quite possibly he will have decided > to take his business elsewhere. > > John F. Fay > joh...@eg... |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-22 21:03:24
|
The corresponding block from GLUT's glut.h... #if defined(_MSC_VER) ... # if !defined(GLUT_BUILDING_LIB) && !defined(GLUT_NO_LIB_PRAGMA) # pragma comment (lib, "winmm.lib") /* link with Windows MultiMedia lib */ /* To enable automatic SGI OpenGL for Windows library usage for GLUT, define GLUT_USE_SGI_OPENGL in your compile preprocessor options. */ # ifdef GLUT_USE_SGI_OPENGL # pragma comment (lib, "opengl.lib") /* link with SGI OpenGL for Windows lib */ # pragma comment (lib, "glu.lib") /* link with SGI OpenGL Utility lib */ # pragma comment (lib, "glut.lib") /* link with Win32 GLUT for SGI OpenGL lib */ # else # pragma comment (lib, "opengl32.lib") /* link with Microsoft OpenGL lib */ # pragma comment (lib, "glu32.lib") /* link with Microsoft OpenGL Utility lib */ # pragma comment (lib, "glut32.lib") /* link with Win32 GLUT lib */ # pragma comment (lib, "winmm.lib") # pragma comment (lib, "gdi32.lib") /* Windows GDI */ # pragma comment (lib, "advapi32.lib") /* */ # pragma comment (lib, "user32.lib") /* */ # endif # endif ... If appears that GLUT only uses pragma for the MS compiler, and also provides GLUT_NO_LIB_PRAGMA as a mechanism to supress them. In FreeGLUT, the affected files are freeglut_std.h and freeglut_internal.h Potentially, this whole block could be migrated to freeglut_win32.h, but my preference would be to leave it in freeglut_std.h. I have also taken the librerty to tidy up the indentation, removed the inclusion of windowsx.h and mmsystem.h, and removed the definition of WINDOWS, which doesn't seem to be used anymore. The mmsystem.h header does need to be included from freeglut_internal.h, as the FreeGLUT depends on it, but the interface does not. ---------------------------------------------------------------- /* * Under windows, we have to differentiate between static and dynamic libraries */ #if defined(_MSC_VER) || defined(__CYGWIN__) || defined(__MINGW32__) # define WIN32_LEAN_AND_MEAN # define NO_MIN_MAX # include <windows.h> # undef min # undef max /* Windows static library */ # ifdef FREEGLUT_STATIC # define FGAPI # define FGAPIENTRY # if defined(_MSC_VER) # pragma comment (lib, "freeglut_static.lib") /* link with Win32 static freeglut lib */ # endif /* Windows shared library (DLL) */ # else # if defined(FREEGLUT_EXPORTS) # define FGAPI __declspec(dllexport) # else # define FGAPI __declspec(dllimport) # if defined(_MSC_VER) # pragma comment (lib, "freeglut.lib") /* link with Win32 freeglut lib */ # endif # endif # define FGAPIENTRY __stdcall # endif /* Drag in other Windows libraries as required by FreeGLUT */ # if defined(_MSC_VER) # pragma comment (lib, "winmm.lib") /* link with Windows MultiMedia lib */ # pragma comment (lib, "user32.lib") /* link with Windows user lib */ # pragma comment (lib, "gdi32.lib") /* link with Windows GDI lib */ # pragma comment (lib, "opengl32.lib") /* link with Microsoft OpenGL lib */ # pragma comment (lib, "glu32.lib") /* link with OpenGL Utility lib */ # endif #else /* Non-Windows definition of FGAPI and FGAPIENTRY */ # define FGAPI # define FGAPIENTRY #endif ------------------------------------------------------ freeglut_internal.h ... /* * Somehow all Win32 include headers depend on this one: */ #if TARGET_HOST_WIN32 #include <windows.h> #include <windowsx.h> #include <mmsystem.h> #endif #if defined(_MSC_VER) #define strdup _strdup #endif ------------------------------------------------ Nigel Stewart and Fiona Smith wrote: > Given that GLUT has used #pragma for a long time, I would > be surprised if there were too many cases that they could > pose a problem. I will review my changes and propose an > approach shortly. > > Nigel |
From: Richard R. <sf...@ol...> - 2003-12-23 10:14:13
|
On Tue, Dec 23, 2003 at 08:04:52AM +1100, Nigel Stewart and Fiona Smith wrote: [...] > I have also taken the librerty to tidy up the indentation, > removed the inclusion of windowsx.h and mmsystem.h, > and removed the definition of WINDOWS, which doesn't > seem to be used anymore. The mmsystem.h header does need > to be included from freeglut_internal.h, as the FreeGLUT > depends on it, but the interface does not. You might also want to watch some of the overlong lines, if the code is going into the general sources. (Several of your comments ran past column 80, and will display badly on many editors/terminals if the user isn't using the MS Visual Studio (or KDevelop, which seems to model itself on MS Visual Studio).) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-23 12:29:36
|
> You might also want to watch some of the overlong lines, if the code > is going into the general sources. Oh OK. My thinking has shifted away from an 80 character convention, but I'm content to follow the FreeGLUT convention for FreeGLUT code... Nigel |
From: Richard R. <sf...@ol...> - 2003-12-23 12:59:21
|
On Tue, Dec 23, 2003 at 11:31:14PM +1100, Nigel Stewart and Fiona Smith wrote: > > >You might also want to watch some of the overlong lines, if the code > >is going into the general sources. > > Oh OK. My thinking has shifted away from an 80 > character convention, but I'm content to follow the > FreeGLUT convention for FreeGLUT code... I don't know what the majority of other developers use or do, so I guess I should be a little circumspect... However, emacs on my system comes up with an 80 column window (sizing the window appropriately). Likewise xemacs. My xterms are 80 columns by default, so if I use vi or more to browse code therein, again it's at 80 columns. Nevermind the case where I am on a text console (up and down on that score, but it does happen). There I don't even have the option to resize to a higher width. My view is that 80 columns is still probably the most common. If I were the only person affected by this, I'd just deal with it, but I suspect that I am not. (^& Also, if you want those changes to be committed (I'm not clear if you have the access, though I think that you've asked me to commit something or two on your behalf before), it would be easier to do them as a MIME file attach, or something. Cutting and pasting from email often introduces more artifacts. If other WIN32 users have no objections, and we are agreed to treat this as a bug in suspension (to be fixed if it ever is realized), then I would be happy to commit those files for you. It would be easier if they were attached to an email, though. (^& (P.S.: Good news. Disabling "ioapic"---whatever that is---seems to have fixed my Intel ethernet card problems. This probably shouldn't be necessary, but now I'm looking at building MozillaFirebird on the AMD64 box. Whee. Zip. Except it doesn't build. But I won't be put off by a recalcitrant flaming arcahaeopterix, no sir!) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-23 14:01:07
|
> Also, if you want those changes to be committed (I'm not clear if you > have the access, though I think that you've asked me to commit something > or two on your behalf before), it would be easier to do them as a > MIME file attach, or something. Cutting and pasting from email often > introduces more artifacts. OK, will do. I'll just to need to check that my FreeGLUT isn't too far out of sync with anon CVS... > If other WIN32 users have no objections, and we are agreed to treat > this as a bug in suspension (to be fixed if it ever is realized), > then I would be happy to commit those files for you. It would be > easier if they were attached to an email, though. (^& Yes, we could document it as a "potential issue", but I'm not sure of the appropriate wording - /* #pragma may not be supported by some compilers, * discussion by FreeGLUT developers suggests that * Visual C++ specific code involving pragmas may * need to move to a separate header. */ Nigel |
From: Eric S. <er...@sa...> - 2003-12-30 22:05:36
|
Quoting Richard Rauch <sf...@ol...>: > I don't know what the majority of other developers use or do, so I guess > I should be a little circumspect... > > However, emacs on my system comes up with an 80 column window (sizing the > window appropriately). Likewise xemacs. My xterms are 80 columns by > default, so if I use vi or more to browse code therein, again it's at > 80 columns. > > Nevermind the case where I am on a text console (up and down on that score, > but it does happen). There I don't even have the option to resize to a > higher width. If you use your video card's framebuffer, you can have any size it will support (both my X and console are at 1280x1024). > My view is that 80 columns is still probably the most common. If I were > the only person affected by this, I'd just deal with it, but I suspect > that I am not. (^& Most of my terminals/editors are also set at 80, though I resize them when I find code/text which doesn't fit. <snip> > (P.S.: Good news. Disabling "ioapic"---whatever that is---seems to > have fixed my Intel ethernet card problems. This probably shouldn't > be necessary, but now I'm looking at building MozillaFirebird on > the AMD64 box. Whee. Zip. Except it doesn't build. But I won't > be put off by a recalcitrant flaming arcahaeopterix, no sir!) My nForce2 board had the same problem, with a similar fix: acpi=off noacpi lapic=off (or some such). -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o? K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++) tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+ ------END GEEK CODE BLOCK------ Eric Sandall | Source Mage GNU/Linux Developer er...@sa... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Richard R. <sf...@ol...> - 2003-12-31 00:21:21
|
On Tue, Dec 30, 2003 at 02:05:34PM -0800, Eric Sandall wrote: > Quoting Richard Rauch <sf...@ol...>: > > I don't know what the majority of other developers use or do, so I guess > > I should be a little circumspect... > > > > However, emacs on my system comes up with an 80 column window (sizing the > > window appropriately). Likewise xemacs. My xterms are 80 columns by > > default, so if I use vi or more to browse code therein, again it's at > > 80 columns. > > > > Nevermind the case where I am on a text console (up and down on that score, > > but it does happen). There I don't even have the option to resize to a > > higher width. > > If you use your video card's framebuffer, you can have any size it will support > (both my X and console are at 1280x1024). There is occasional talk about implementing something like the GNU/LINUX framebuffer device in the kernel... I don't think that it's been done by anyone yet. Not on i386 where a "real" text console is ingrained. (But the internationalization people want it for larger character sets, as well, so it is likely to happen eventually.) My X server is at 1280x1024 pixels. My console is at 80x25 cols/rows, but virtual terminal #4 (or #3? I forget if they count from 0 or 1; (^&) is 80x50. I don't know that anything else is supported. ...then I have a WIN32 system recently salvaged, and a brother has promised to send me a spare MSVC++ suite. I may try to do some WIN32 freeglut work on it, but the monitor is one I've kept as a backup for years. The monitor is blurry and dim, and more than about 80 columns would be pushing my luck in terms of legibility. The upshot is: Changing resolution is not always an option. > > My view is that 80 columns is still probably the most common. If I were > > the only person affected by this, I'd just deal with it, but I suspect > > that I am not. (^& > > Most of my terminals/editors are also set at 80, though I resize them when I > find code/text which doesn't fit. Depends on what I'm doing and where I'm at. Text console on NetBSD? Not an option. *Any* OS on that old monitor above? Don't hold your breath. Printing with a2ps? Maybe there's an option to adjust line-length, but I'm not sure. What's worse is that if code sticks to 80 columns, that's a long-standing de facto standard. If it goes beyond 80 columns, just *how* big do you need, by way of a monitor, and *how* small does your font need to be? Resize the window, shrink the font, and hope that the author didn't set a minimal font on a 1600x1200 (or larger) screen. If I'm just reading the code to appreciate how it was implemented (not able or willing to debug it or add features), I might just grab a code beautifier and have it "fix" the code for me. (^& (I don't trust such tools on code that I am trying to work on, though...) > <snip> > > (P.S.: Good news. Disabling "ioapic"---whatever that is---seems to > > have fixed my Intel ethernet card problems. This probably shouldn't > > be necessary, but now I'm looking at building MozillaFirebird on > > the AMD64 box. Whee. Zip. Except it doesn't build. But I won't > > be put off by a recalcitrant flaming arcahaeopterix, no sir!) > > My nForce2 board had the same problem, with a similar fix: acpi=off noacpi > lapic=off (or some such). This is nForce3. Maybe nVidia is screwing up ioapic royally, if two totally unrelated operating system kernels have this kind of problem. Ick. I'll forward that datapoint to the NetBSD developer I was talking to about my problems. Is this a well-discussed problem on GNU/LINUX lists? Thanks, especially for the last tidbit. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-31 00:57:45
|
> ...then I have a WIN32 system recently salvaged, and a brother has promised > to send me a spare MSVC++ suite. I may try to do some WIN32 freeglut work > on it, but the monitor is one I've kept as a backup for years. Another Win32 option is Dev C++, an IDE based on gcc and Mingw32. http://www.bloodshed.net/devcpp.html I have a set of project files, (.dev) which I could either email or roll into CVS. I also created a FreeGLUT DevPak (headers and library) http://www.nigels.com/glt/devpak/ A .dev file is roughly the same as a MSVC .dsp project file. Dev C++ generates a temporary makefile for building from the .dev. Other available DevPaks via: http://www.bloodshed.net/dev/packages/index.html http://molhanec.net/devpaks/index.php The environment itself I find a little bit quirky, but quite a viable alternative to Visual C++. I have not yet succeeded with ./configure on Cygwin or MingW32, but Dev C++ works quite well with the current freeglut CVS and is true gcc/Win32 without the Cygwin emulation layer by default. nigels@zooropa /m/SourceForge/freeglut/freeglut$ find -name "*.dev" ./progs/demos/CallbackMaker/CallbackMaker.dev ./progs/demos/Fractals/Fractals.dev ./progs/demos/Fractals_random/Fractals_random.dev ./progs/demos/Lorenz/lorenz.dev ./progs/demos/One/one.dev ./progs/demos/shapes/shapes.dev ./src/freeglut.dev Nigel |
From: Richard R. <sf...@ol...> - 2003-12-31 01:22:37
|
On Wed, Dec 31, 2003 at 11:59:23AM +1100, Nigel Stewart and Fiona Smith wrote: > > >...then I have a WIN32 system recently salvaged, and a brother has promised > >to send me a spare MSVC++ suite. I may try to do some WIN32 freeglut work > >on it, but the monitor is one I've kept as a backup for years. > > Another Win32 option is Dev C++, an IDE based on gcc and Mingw32. > http://www.bloodshed.net/devcpp.html > > I have a set of project files, (.dev) which I could either email > or roll into CVS. I also created a FreeGLUT DevPak (headers and If all that's missing is a set of project files, I don't know if anyone would have any objection to just adding them. I would suggest that someone make a map of the .dsp, .dsw(?), .dev, and other compiler-specific project files. As for me, I'm taking one step at a time, and don't really want to get too committed to this WIN32 stuff. ("Whats the difference between being involved and being committed? Well, take this breakfast of scrambled eggs and sausage. A chicken was involved, but a pig was committed.") Since my brother has promised to send me his spare MSVC++, and I'm still ironing out CygWIN issues, I'll hold off on Dev C++. I'm also thinking of swapping the "new" (rather ancient) WIN32 box with a PIII 350MHz with 64MB RAM. (The current WIN32 box is, I think a PII. It's running at 266MHz I'm pretty sure, and has 32MB of RAM. Even starting up BASH and and doing basic POSIX commands like "ls" and "pwd" is hitting a lot of swap. However, the machine is plenty powerful to be a nice little UNIX-like server for my modest needs.) > The environment itself I find a little bit quirky, but quite a > viable alternative to Visual C++. I have not yet succeeded with > ./configure on Cygwin or MingW32, but Dev C++ works quite well > with the current freeglut CVS and is true gcc/Win32 without the > Cygwin emulation layer by default. ...I was hoping to build freeglut on CygWIN's POSIX/X11 layer. Since the box isn't on the Internet directly, I copied my working freeglut directory over the LAN via "scp" (oh! for an NFS mount; (^&) an need to re-run autogen.sh and ./configure. One error was reported, but it seems to have kept on running to completion, so I'm trying a ./configure. It is *slow* though. It might not finish a build of freeglut tonight, assuming it doesn't hit a show-stopping error. Oh well... I'll let it grind till it stops or the local tectonic plate subducts into an oceanic trench. (^& BTW, do you know why "xload" isn't included with CygWIN (totally off-topic at this point; sorry...)? I like to keep an xload running at least for the local machine when I run X, but this machine doesn't seem to have it. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Eric S. <er...@sa...> - 2004-01-05 17:01:46
|
Quoting Richard Rauch <sf...@ol...>: > On Tue, Dec 30, 2003 at 02:05:34PM -0800, Eric Sandall wrote: <snip> > > My nForce2 board had the same problem, with a similar fix: acpi=off noacpi > > lapic=off (or some such). > > This is nForce3. Maybe nVidia is screwing up ioapic royally, if two totally > unrelated operating system kernels have this kind of problem. Ick. I'll > forward that datapoint to the NetBSD developer I was talking to about my > problems. > > Is this a well-discussed problem on GNU/LINUX lists? > > > Thanks, especially for the last tidbit. (^& It's been quite documented on the LKML[0]. I can look up the threads if you like, or a quick search for "nforce" or "nvidia" will pull them up. ;) There are quite a few threads, and some of them are fairly long. The latest Linux 2.6.0 kernel with the -mm1 patchset has the problems fixed (at least I don't need to boot with any special APIC options for my machine to work now). I have not been too pleased with nVidia's motherboard products, nor their lack of support for open source driver writers. -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o? K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++) tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+ ------END GEEK CODE BLOCK------ Eric Sandall | Source Mage GNU/Linux Developer er...@sa... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Eric S. <er...@sa...> - 2004-01-05 17:24:28
|
Forgot the link... [0] http://marc.theaimsgroup.com/?l=linux-kernel -sandalle Quoting Eric Sandall <er...@sa...>: > It's been quite documented on the LKML[0]. I can look up the threads if you > like, or a quick search for "nforce" or "nvidia" will pull them up. ;) There > are quite a few threads, and some of them are fairly long. The latest Linux > 2.6.0 kernel with the -mm1 patchset has the problems fixed (at least I don't > need to boot with any special APIC options for my machine to work now). > > I have not been too pleased with nVidia's motherboard products, nor their > lack > of support for open source driver writers. > > -sandalle -- PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61 http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS/E/IT$ d-- s++:+>: a-- C++(+++) BL++++VIS>$ P+(++) L+++ E-(---) W++ N+@ o? K? w++++>-- O M-@ V-- PS+(+++) PE(-) Y++(+) PGP++(+) t+() 5++ X(+) R+(++) tv(--)b++(+++) DI+@ D++(+++) G>+++ e>+++ h---(++) r++ y+ ------END GEEK CODE BLOCK------ Eric Sandall | Source Mage GNU/Linux Developer er...@sa... | http://www.sourcemage.org/ http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU http://counter.li.org/ #196285 | http://www.shock.wsu.edu/ ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Richard R. <sf...@ol...> - 2004-01-05 22:06:24
|
On Mon, Jan 05, 2004 at 09:01:42AM -0800, Eric Sandall wrote: > Quoting Richard Rauch <sf...@ol...>: > > On Tue, Dec 30, 2003 at 02:05:34PM -0800, Eric Sandall wrote: > <snip> > > > My nForce2 board had the same problem, with a similar fix: acpi=off noacpi > > > lapic=off (or some such). > > > > This is nForce3. Maybe nVidia is screwing up ioapic royally, if two totally > > unrelated operating system kernels have this kind of problem. Ick. I'll > > forward that datapoint to the NetBSD developer I was talking to about my > > problems. > > > > Is this a well-discussed problem on GNU/LINUX lists? > > > > > > Thanks, especially for the last tidbit. (^& > > It's been quite documented on the LKML[0]. I can look up the threads if you Thanks. That basically tells me what I hoped: If the NetBSD kernel people don't know about the issues, and if they can't cross-fertilize the right genes from FreeBSD, OpenBSD, or Dragonfly, they can research it via google. So, unless I want to crack bug myself, I can leave it off with a comment already made on a PR (Problem Report). [...] > I have not been too pleased with nVidia's motherboard products, nor their lack > of support for open source driver writers. Nor I. Though I went with the nForce3 because I had heard people say relatively good things about the nForce2 with NetBSD. Given that my immediate alternative appeared to be any one of N VIA-based motherboards, or else an Intel CPU, I do not really regret the nForce3 (yet?). But I'm less than thrilled. (For video cards, I'm avoiding them altogether, since they are of very little value if you aren't running WIN32 or GNU/LINUX.) -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-22 20:01:34
|
Ah, I think one or both of us (the set definitely includes me) isn't understanding the state of things. I had seen the "#include" file idea proposed and considered to be an ugly hack. Since I appreciate beauty of code I considered that grounds for not implementing it without a very good reason, and I didn't consider a hypothetical compiler that wouldn't allow a "#if" to shield a "#pragma" to be a very good reason. (The operative word in its not being a very good reason is "hypothetical"; show me a real one that we should support and I'll change my tune in a heartbeat.) Incidentally, since GLUT uses "#pragma" we could too under the rules of strict compatibility. I personally think that this is a case of reproducing GLUT's bugs, though, and I don't consider strict compatibility to be the driving force here. Since you're back online, I assume that your hardware machinations have been successful? <off-topic> The practice of crossing one's fingers started in the early centuries of Christianity when it was under persecution in the Roman Empire. It was a subtle way of signing the cross without being obvious about it. </off-topic> John F. Fay joh...@eg... -----Original Message----- From: Richard Rauch [mailto:sf...@ol...] Sent: Monday, December 22, 2003 1:47 PM To: fre...@li... Subject: Re: [Freeglut-developer] #pragma comment (lib, ...) is Visual C++ Specific On Mon, Dec 22, 2003 at 09:59:33AM -0600, Fay John F Contr AAC/WMG wrote: > I must disagree. If a user files a bug report, he would expect some action > as a result. The only thing we would do is tell him "We considered the Yes, and I would expect it to be fixed, too. > question a long time ago and decided not to support it. If you want I was not under the impression that we had agreed to never support this. I thought that people were so repulsed by the fix that we were loosely considering risking bug, but didn't know that people were actually in favor of not fixing it even in the face of it causing real problems for real people trying to use freeglut. > 'freeglut' to compile on your system you will have to do this:'" and the > resulting file hack will be exactly the same. The only differences will be Going one way is a gamble. Going the other is taking out insurance. I lean towards the insurance side: Tuck the #pragma in a separate file, with a comment in that file explaining why it is done. Then forget that it was done and never read the file again. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Freeglut-developer mailing list Fre...@li... https://lists.sourceforge.net/lists/listinfo/freeglut-developer |
From: Richard R. <sf...@ol...> - 2003-12-22 20:37:32
|
On Mon, Dec 22, 2003 at 01:58:56PM -0600, Fay John F Contr AAC/WMG wrote: > Ah, I think one or both of us (the set definitely includes me) isn't > understanding the state of things. I had seen the "#include" file idea > proposed and considered to be an ugly hack. Since I appreciate beauty of I agree. I also consider #pragma to be an ugly hack, and too embedding linker instructions into the C source code. That is just wrong. (^& I also agree that if old GLUT did this, that is sufficient grounds to do it, ugly or not. Pragmatically (ahem), as long as it is needed for WIN32, and doesn't cause any portability issues, I don't care whether they are "inline", or tucked into separate files. > code I considered that grounds for not implementing it without a very good > reason, and I didn't consider a hypothetical compiler that wouldn't allow a > "#if" to shield a "#pragma" to be a very good reason. (The operative word > in its not being a very good reason is "hypothetical"; show me a real one > that we should support and I'll change my tune in a heartbeat.) Okay. I misunderstood your stance. I thought that you meant, even if such a user showed up, we should not address this. > Incidentally, since GLUT uses "#pragma" we could too under the rules of > strict compatibility. I personally think that this is a case of reproducing > GLUT's bugs, though, and I don't consider strict compatibility to be the > driving force here. The thing is, that's not really part of the API. It's really a part of the build instructions, and strictly belongs in a Makefile or project file or whatever. (IMHO.) Just on the face of it, I wouldn't put it in C sources. Though if it makes a big difference to some users, I'm not terribly opposed as long as it doesn't break stuff to keep it. (^& > Since you're back online, I assume that your hardware machinations have been > successful? Yes and no. The USB <-> RealTek issue may have gone away (though it is random enough that I'm not sure). I had hoped to also get another ethernet card (this one using an Intel chipset) to work; all that the Intel NIC tells me is "fxp0: timeout", alas. The chipset is generally pretty well-regarded, unlike RealTek, but for some reason I'm having troubles still. The side of the computer case still isn't back on, but I am tentatively going to assume that the conflict is suppressed and go about my business for a while. -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-22 21:09:38
|
> I agree. I also consider #pragma to be an ugly hack, and too embedding > linker instructions into the C source code. That is just wrong. (^& Yes, I agree it is a nasty hack - blame Microsoft, perhaps they thought is was a good idea at the time.... Doing things this way is symptomatic of a brain-dead build environment. (Yes, I prefer gmake :-) On the other hand, MS-centric developers are used to this arrangement and can get confused without it. Portability means accomodating some of the weirdness of each platform, IMHO. Nigel |
From: Richard R. <sf...@ol...> - 2003-12-23 10:37:44
|
On Tue, Dec 23, 2003 at 08:11:15AM +1100, Nigel Stewart and Fiona Smith wrote: > > >I agree. I also consider #pragma to be an ugly hack, and too embedding > >linker instructions into the C source code. That is just wrong. (^& > > Yes, I agree it is a nasty hack - blame Microsoft, perhaps > they thought is was a good idea at the time.... Doing things (^& I know. My point is that either way, we have an ugly hack. One is possibly just a little bit more ugly for compounding one with enother. But, it is also possibly just a little bit safer. > this way is symptomatic of a brain-dead build environment. > (Yes, I prefer gmake :-) I think that it's a broader NIHS case, compounded with the fact that it helps them maintain their virtual monopoly to do everything incompatibly. Break file formats, break protocols, break languges. Design new and weird tools. Update/break even their own proprietary formats on a regular basis. The key is to keep users chained to their software by hook or by crook. That's not quite the same as a simple "brain-dead build environment". I think that it's a market strategy. > On the other hand, MS-centric developers are used to this > arrangement and can get confused without it. Portability > means accomodating some of the weirdness of each platform, > IMHO. Depends on how "homey" you want to make it, I guess. Anyway, it's a moot point. As long as we are agreed that, should it actually be necessary, we can and will move the #pragmas to a compiler- dependant .h file, I don't really care. (^& -- "I probably don't know what I'm talking about." http://www.olib.org/~rkr/ |
From: Fay J. F C. AAC/W. <joh...@eg...> - 2003-12-23 14:25:17
|
I would also put a date on the discussion by the "freeglut" developers so that our successors (if we are not around) can look it up in the archives. John F. Fay joh...@eg... -----Original Message----- From: Nigel Stewart and Fiona Smith [mailto:ni...@ni...] Sent: Tuesday, December 23, 2003 8:03 AM To: fre...@li... Subject: Re: [Freeglut-developer] #pragma comment (lib, ...) is Visual C++ Specific <snip> Yes, we could document it as a "potential issue", but I'm not sure of the appropriate wording - /* #pragma may not be supported by some compilers, * discussion by FreeGLUT developers suggests that * Visual C++ specific code involving pragmas may * need to move to a separate header. */ Nigel <snip> |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-18 14:06:09
|
> (1) Should "freeglut" have any "#pragma" preprocessor symbols? I submit > that the answer is very much yes: GLUT uses them in Windows as a means for > pointing the application to which ".lib" file to use. Unless somebody has > another way of doing this without changing the application in any way (by > which I mean source code and project file) we will need the "#pragma" to do > this. It should be wrapped thoroughly in a "#if" block so that non-MSVC > compilers never see it, though. (Should we put it in its own > "freeglut_win32_msvc_include.h" file, as Richard said would shield it > completely?) Agreed. > (2) The "#pragma message" warning in "freeglut_window.c" simply prints out a > warning at compile time. I think we could replace that with one of > Richard's "XXX" comments (those are a very good idea, by the way) and not > harm anything. Agreed. > (3) Right now there are two primary divisions within "freeglut": > TARGET_HOST_UNIX_X11 and TARGET_HOST_WIN32. Within the former we have > "__FreeBSD__" and "__NetBSD__" (and possibly others) while within the latter > we have "__CYGWIN__" and "CYGWIN32__" and we are talking about adding a few > more. It strikes me that these subdivisions are somewhat disorganized. I > would like to see some structure here: somewhere in the code (probably at > the beginning of "freeglut_internal.h") we should have a list of platforms > and compilers supported and which symbols are set to one on which platform > and defined for which compiler. Agreed. Part of the problem is that freeglut_internal.h does _some_ of this logic in a way that needs to be synchronised with freeglut_std.h Windows needs to be treated in some case differently due to compiler and environment. Having distinct _MSC_VER or __CYGWIN__ is necessary - these can always be lumped into a generic TARGET_HOST_WIN32 Nigel |
From: Nigel S. a. F. S. <ni...@ni...> - 2003-12-18 14:22:42
|
oops... > Having distinct _MSC_VER or __CYGWIN__ > is necessary - these can always be lumped into a generic ^^^^ cannot > TARGET_HOST_WIN32 |