Re: [ECOS] building gcc-2.95.1 for eCos 1.2.1

[Grant Edwards <grante@visi.com>]

> Yes, I built a sample app and it compiles fine using eCos's
> arm-elf-gcc.  I was then able to load it to my ARM evaluation board
> and run it with arm-elf-gdb without any problems.

OK, it's good to have a baseline of know working components upon on
which to build.

> -------------------------------------
> If you're going to be running an embedded system with
> eCOS, then you don't need glibc -- all you need is
> gcclib.
> -------------------------------------

> All the documentation I found on building an ARM-Linux cross
> toolchain told me to build glibc.

That documentation probably assumed that you wanted to build a
compiler that was going to be used to compile programs to be run on a
Linux/ARM system -- which would support glibc.  glibc requires a
Unix/Linux OS underneath it to provide the system calls required by
many of the library routines.  AFAIK, eCOS doesn't provide support to
use glibc in an embedded system.

There may be a subset of glibc that can be used in an embedded system,
but generally people use newlib instead of glibc for embedded work.
The cross-compiler FAQ URL I provided earlier discusses this problem
in more detail.

> I am guessing that this is the problem.  As I mentioned before, I
> have built gcc-2.95.1 and glibc-2.1.2 for an ARM-Linux target.  The
> compiler seemed like it was able to compile alright but the
> arm-elf-gdb didn't seem to like the file.

That's odd, then.  If you do a "file" command on the file you're
trying to load does it say something like:

 ELF 32-bit MSB executable, Advanced RISC Machines ARM, version 1

If you do an arm-elf-objdump --headers on the file, do the sections
all show up at the right addresses?  If you're using a "PID" eval
board they should all get mapped into RAM starting at 0x04000.

Remember that when linking a file to be run on an embedded system, you
have to use a linker command file that specifies exactly where in
memory each section is to be loaded.  It must also be statically
linked with no unresolved external symbols.

> I will try to build the compiler again with only gcclib.  However,
> the reason I am building this compiler is because I want to be able
> to use gcj, am I going to come across probelms with libgcj?

I don't know what support libgcj requires.  If it is a stand-alone
library like libgcc, then there's a chance it might work. If libgcj
calls stuff in glibc or other libraries, then it depends on how those
requirements can be satisfied under eCOS.

-- 
Grant Edwards
grante@visi.com