[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 :-)