Re: Crosstool 0.28 failure building mipsel on cygwin

[Kai Ruottu <karuottu at mbnet dot fi>]

Joel Sumner wrote:

> First of all, thanks to all of the folks who are trying to make building 
> a gcc cross compiler easier. I told my coworkers that I was looking into 
> building a gcc cross compiler and I got looks of amusement mixed with 
> horror.  I've spent the last few days wrestling with old and obsolete 
> instructions:
>
> http://www.onkelinx.com/agenda/compiling_toolchain.html
> http://www.village.org/villagers/imp/build.html
> http://www.student.cs.uwaterloo.ca/~cs350/common/make-linux-gcc.html

 After building more than 1000 crosscompilers during the past years, I still
don't think people really trying to build crosscompilers here although claiming
to do that... The right term could be porting Linuces for some hardware which
yet doesn't have a Linux port for it. Or the available Linux ports for the arch
are somehow faulty like when trying to port to a non-PC architecture x86 system
like some old 'Altos' (bought by Taiwanese Acer) which used MP/M-86, SCO Xenix
and last SCO Unix on its multi-user non-PC hardware...

 A crosscompiler for Red Hat Linux 7.3 hosted on SuSE 9.2 could be more normal
as a crosscompiler, the target system already has a Linux port for it and one
only wants to crosscompile stuff for this target system, not replace the
existing Linux on it. All those PDAs, WiFi-routers etc. coming with an existing
Linux or uCLinux are more traditional as the target platform...

> This configuration is mentioned in demo-mipsel.sh as working with the 
> Linksys WRT54G router and that configuration is also mentioned as being 
> good at http://kegel.com/crosstool/#results.

 Ok, I too have considered to buy this Linksys router with ucLinux on it. But
then my goal first could be to be the root user there and try to produce some
simple apps to run on it, by producing crosstools for this target system, using
its own uClibc as the target C library and such, behaving in the same way as I
have behaved with all the 1000+ crosstools earlier...

 So my stupid question is: What is wrong with the WRT54G so that producing
normal crosstools for it is impossible? Does Linksys hurt the GPL somehow
and don't provide sources and binaries for their Linux distro?

Hmmm, here is a message from comp.arch.embedded :

---------------------- clip ---------------------
From: Carsten <xnews1@luna.kyed.com>
Newsgroups: comp.arch.embedded
Subject: Re: Cheapest micro running linux?
Date: Fri, 03 Dec 2004 18:51:26 +0100

Maybe a linksys WRT54G Wireless router.

200-Mhz MIPS-CPU ,  4M-Flash , 16M-Ram , 5 x ethernet ports ,
1 x 54Mb Wi-Fi , allready runs uC-linux , and Linksys GPL'ed the code,
as required , and even included a full MIPS Linux Toolchain(binary) in
the Sourcepackage.

If you add a MAX233 , to the board (solder pads are there) , then you
get 2 x Rs232.

The WRT54GS , has double Ram+Flash , but costs a little more.

Think WRT54G  around $70


Carsten
---------------------- clip ---------------------

The words "included a full MIPS Linux Toolchain(binary) in
the Sourcepackage" claim that Linksys doesn't do anything like that in
order to become sued by FSF... And that producing crosstools for some
other host than that supported by the Linksys binaries, should be easy
and totally normal cross-GCC producing... But what is the truth?

People here should know how to produce normal crosstools before deciding that
it is not possible in some case and then starting to try the Dan's scripts
and start everything almost from scratch, only the host tools being as
prebuilt when in the normal cross-GCC case the target C library is always
prebuilt in the beginning (the embedded newlib-based tools being the
exceptions but then there are no native tools possible...). The traditional
(and normal) way to produce a cross-GCC is the way used in the so-called
"final-GCC" stage in Dan's scripts (or how I have understood without ever
needing them...), or in a update case where one already has binutils, GCC
and glibc in the beginning - the old self-built stuff will not be thrown
into garbage but used during the update process in the same way as it would
be used in a native build. Never heard anyone trying to build a native GCC
and a native glibc after removing the '/lib', '/usr/include' and '/usr/lib'
stuff which belongs to the old glibc. Neither removing the old GCC before
trying to build a new GCC from its sources is very common...

> It made it through building binutils and gcc but it falls over a ways 
> through building glibc

 Is it really possible to replace the much smaller ucLinux with uClibc on
WRT54G and replace it with a full-blown real Linux with glibc ? Anyone ever
produced crosstools for the Linksys own "Linux"?  For some ARM or MIPS based
PDA with existing Linux?  For Red Hat ?  For SuSE ?

 If quoting Bod Dylan: "Where have all the cross-GCC builders gone, long time
passing...."


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com