 | | Re: Directions to compile GCC
|
|
(...) This may not be the case- the cross-compiler will try to compile something, but at least with the directions most of us use, there is no standard C library created and so the compiler thinks it doesn't work. The trick (then) is to use Markus's (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Directions to compile GCC
|
|
"Markus L. Noga" <markus@noga.de> : (...) Thanks! In one of the sections under this document there is a short paragraph explaining that cross compilers may not like having 32 bit ints (Like BeOS uses) turn into 16 bit ints (Like I bet the RCX uses) (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Directions to compile GCC
|
|
Jim Jackson <jjackson@jnjackson.com> : (...) GCC-2.95.2 (...) --host=i586-pc-beos (...) This gave me the Idea to tell the configure that I was running a Linux box (instead of a bebox) It almost worked too. At the end of the make the machine says I (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Odd behavior
|
|
(...) currently i believe there is some really subtle bug in malloc(), that shows up only under special circumstances. I experience similar problems with a fat kernel/application that disappear after adding one cputw(), making the binary a little (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
| |
| | Re: Odd behavior
|
|
(...) Or worse, MacOS. I use and love my Macs, but lord they sure don't have much crash protection right now. I just wish there was a way to avoid having to reload the firmware every time it breaks, but I suppose that without an MMU, that's a bit (...) (25 years ago, 28-Feb-00, to lugnet.robotics.rcx.legos)
|
