On Wed, Jun 24, 1998 at 08:48:52PM +0200, Thomas Bogendoerfer wrote:
> On Wed, Jun 24, 1998 at 03:24:17PM +0200, Michael Engel wrote:
> > there seems to be some kind of black magic needed to compile milo-0.27
> > (which is the most recent version I found) ...
> there is a milo-0.27.1 (maybe it's still on ftp.fnet.fr). You will need
> this version for your RM200.
> > Could it be a problem with my crossdevelopment tools (gcc-2.7.2 and
> > binutils-2.8.1) or do I need a specific kernel source code version in
> > order to compile milo-0.27 ?
There were certain dirty dependencies from the kernel source and even libc
in the Milo source; these should mostly be gone by now.
> I've compiled milo-0.27.1 with the same crossdevelopment tools a couple
> of minutes ago. I only had to modify libstand/memset.c as the declaration
> of memset in that file is really bogus. And I've disabled the deskstation
> stuff, because it didn't compile the first time, and I don't need it.
The Milo executable is a ECOFF file and generating ECOFF with a ELF
toolchain as we have it for Linux/MIPS is very fragile. Fixing this
would be _major_ brain surgery to binutils. Milo 0.27.1 therefore
takes the other way and uses an ELF to ECOFF converter in order to generate
ECOFF files with SVr4 PIC code. Actually is a truly pervert mixture
of SVr3 and SVr4 ABIs for a non-UNIX piece of code. But we have to do it
in order to deal with the SNI firmware which never loads a loaded program
to the address specified in the ECOFF headers. That's ok by the ARC
firmware specs which says code has to be relocatable or to contain
relocs but it's also highly unintuitive behaviour. I introduced this
for Milo 0.27.1; older versions are very fragile due to the zillions of
cross-format linking bugs in binutils.
In short, take Milo 0.27.1 as base for any Milo hacking; older versions
might behave really nasty especially with a version of binutils they
haven't been written for.