linux-mips-fnet
[Top] [All Lists]

Re: sgi crossdev

To: linux-mips@fnet.fr
Subject: Re: sgi crossdev
From: Systemkennung Linux <linux@mailhost.uni-koblenz.de>
Date: Thu, 4 Apr 1996 14:52:26 +0200 (MET DST)
In-reply-to: <199604041224.OAA06068@pallas.spacetec.no> from "Tor Arntsen" at Apr 4, 96 02:23:59 pm
Hi all,

> If there's any interest I could prepare and upload SGI/IRIX cross-dev tools 
> (gcc, binutils).  But first I need to know a couple of things:
> 
> - Should I bother?  (I will have to re-build the tools because I don't 
>   currently have them in /usr/local.)
>   Or could we just assume that anyone interested in Linux/MIPS who 
>   intends to do cross-compiling on the nearest SGI box can easily enough
>   whip up the tools him/herself without too much trouble?  (And, unlike most
>   of those using a Linux/x86 for cross development, many SGI users certainly 
>   wouldn't want a /usr/local setup (say, no root access), and would need to 
>   build their tools for their own setup anyway.  Of course the same could be
>   said about the SunOS/Solaris tools that already exist on fnet..

/usr/local/ or some package in /opt sound reasonable to me.  The no-root
access is probably less important since most of the people that do kernel
hacking are sysadmins anyway ...

> - If I do, what would be the preferred layout/content?  Should I do it e.g. 
>   the (ftp.fnet.fr) crossdev/i486-linux style, with mipsel-linux,
>   mipsel-linuxelf directories/tools, or should I just make one big honkin' 
>   tar file with ./usr/local/mipsel-linuxelf, ./usr/local/mipsel-linux[aout], 
>   ./usr/local/lib/gcc-lib/[..], ./usr/local/bin/[..] etc.
>  (I'm not sure if I would want to bother with the bigendian versions at the
>   moment, as I won't be able to test them.)

The bigendian stuff builds but it as long as noone is actually really working
on with it I think this is just wasted time and disk space.

>   Is there any chance that in the near future we will have a kernel that 
>   can be compiled ELF so I could leave out the aout version?  (however it
>   doesn't add much effort to make it as soon as I set up the environment,
>   it's mostly a question of how big the tar file gets..)

Finally eleminating the complete a.out stuff is one of the things on my todo 
list.
When I do this systemflavours mips*-*-linux and mips*-*-linuxelf will be the 
same.

> If there's interest I'll be happy to do it.  To do the build would be a matter
> of minutes (make -j and a multi-cpu Challenge helps a lot), but it would 
> still take some days though:

Would you mind to borrow me your Challenge ;-)  Well, now that Dave has working
SMP I think I should try to get ...

> - I have to get fresh sources.  My gcc 2.7.2 sources (which I use everywhere 
>   here) have been modified so that the (IMO) stupid mis-feature of accepting 
>   '//' comments is backed out.  If people start using such comments here at 
>   our site (and be sure some of them do!) it crashes with all the other 
>   compilers we have here so..

Well, I like the // feature alot.  I tried not to have them in the released 
sources
but expect these sooner or later to creep in.  That // might break the semantics
of some braindead code is IMHO no problem of interest in real live.

>   But there is at least one file in the current Linux/MIPS sources with such
>   a comment and I guess it's better to use the 'standard' 2.7.2 for least-
>   surprice reasons.
> - However, I would like to keep the 'fstrength-reduce' bug fix, now quite
>   common I believe.

My published sources already contain a fix for this bug.

> - I have to set up some hardware (eg. a fresh /usr/local) for this purpose.

Not really necessary for this purpose.  Try

   make install prefix=/tmp/installdir/usr/local

for creating such binary package.

> The easter days (more like a week actually, in Norway) would be perfect for 
> this, so please somebody let me know if I should go ahead or if I would be 
> wasting my time (it's probably better for me to go skiing!)

Too bad - not enough snow left for skiing here ...

   Ralf

<Prev in Thread] Current Thread [Next in Thread>