Re: GCC 4.1: Buildable on GHz machines only?
Huh? I can cross-compile GCC, its all the packages that require native configuration/building Is it fesable for people in this sort of situation to build GCC on a fast machine but with the final host and target both set to whatever the slower machine is (in this case coldfire) Does GCC even support that?
Re: libgcc_s.so.1 exception handling behaviour depending on glibc version
> Neither does Linux - by linking against a recent library you are > *asking* for a binary that requires that library. If you understand > that you might understand why everyone is saying you should build on the > lowest common denominator of the systems you're targetting. > > If you insist on shipping executables not just source then you have to be > prepared to make a bit more effort to make them distributable. You're > aware of the problems, but seem to be resisting everyone's advice on how > to avoid them. On windows, it is possible to build a binary using a compiler on Windows XP that can then run on older versions of windows simply by not using any features specific to the newest versions of windows XP (or by using LoadLibrary and GetProcAddress to see if those features are available or not). Can you do the same thing on linux?
Re: signed is undefined and has been since 1992 (in GCC)
- sizeof(int) == 4, sizeof(long long) == 8 I swear 16 bit compilers have sizeof(int) = 2 with sizeof(long) = 4
Re: http://gcc.gnu.org is turning away MS Internet Explorer 5
I just tried with Internet Explorer 6 (as installed by Windows XP Service Pack 2) and it worked just fine. Did you try another browser (e.g. Mozilla or Firefox)?
Re: try/finally in GNU C
> The discussion kind of wandered off, but I'd like to note that I am in > favor of adding __try/__finally as a GNU extension for both C and C++. > It's true, of course, that it's just syntactic sugar which can be > implemented in other ways, but sometimes sugar is sweet. How would this mesh with a possible implementation of __try and __finally (and friends) as implemented by Visual Studio on win32? Having those keywords implemented on the win32 port of GCC (and working exactly like/being compatible with Visual Studio) would be nice :) (no, I am not offering to write the patch :) If anyone knows of any reason why implementing MS compatible exception handling in GCC on win32 would not be possible, that would be great to know :)
