[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] [Mint-cvs] [FreeMiNT CVS] freemint/sys/sockets/inet4


Den 01.01.2010 23:05, skrev Jo Even Skarstein:
Mark Duckworth wrote:

Ok, I am able to get maximum free memory on 14mb falcon afer mint of
11,176K.  A make distclean runs out of memory even.  So there is no way
to build freemint on a stock falcon with gcc 2.95.3 even.

I don't remember the details, but under certain circumstances I ran out
of memory on my 32Mb Afterburner while building MiNT with 2.95. So I'm
not surprised that it doesn't work on a 14Mb Falcon.

Anyway, gcc is so slow that it's not practically usable on a plain
Falcon. Why are we using this compiler? Because of the lack of alternatives?

Well. I think we've got alternatives, but those alternatives is a dead end imo. On the other hand, GCC have become too heavy for our hardware to manage. So, to me it looks like we're in a "chicken and egg" situation. For me, the alternatives are no option, as i feel that the only chance we have of ever getting FreeMiNT/XaAES to run on other hardware is to stick with GCC. I accept the fact that I can never build the kernel on a 16-meg TT/Falcon. I can, however, do that on my 512Meg CT60, or cross-compile on my Fedora-Linux PC. That is a tradeoff I can live with, as long as it gives me some sort of reassurance that GCC will make it easier to get onto other hardware.

The best way would, ofcorse, be to have our sources compile on both the alternative compilers and GCC. But, as I have stated before, I do not have time to maintain source-compatibility with other compilers than with the compiler of my choise.

What do we do about this situation? I dont know. I know that I am not interested in, or have time to, installing several compilers in order to maintain compatibility. My main developmentenvironment is GCC 4.4.2/KDE on Fedora. On this beast, it takes 16 seconds to build the kernel from distclean. I dont want to loose that luxury :)

One solution could be we branch off the CVS, one for sources that will build on the native alternative compilers and one for GCC sources. With this solution, persons not interested in finding a way to use GCC can get together and back-port stuff from GCC and vice versa. Since I think persons wanting to stick with native compilers wont be using GCC, and vice versa, it will be very difficult keeping this under control via #ifdefs within a single source tree. And I hate these kinds of #ifdefs :-)

 Best regards
Odd Skancke