> 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
When I do this systemflavours mips*-*-linux and mips*-*-linuxelf will be the
> 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
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 ...