recommendation for toolchain

Building a cross-GCC for Linux shouldn't be any harder than building a cross-GCC for any other system target, ie. a target which has a native-GCC available for it. In this case the cross-GCC is only an incarnation of the native-GCC on another host... What makes it hard is that this fact is not understood and too many people think that they must always start from scratch. They are like smiths needing to produce a new hammer and denying to use any 3rd party or self-made old hammer in the production, using stones and ore instead of pre-made hammers and pre-made stee...

You are in the right track now....

When producing GCC one needs premade binutils and a premade C library for the target. The premade C library needs only to be suitable to be used during the GCC build, one can always produce the final C library (glibc here) from its sources when the GCC is first ready and working with the temporary 'suitable' C library.

So if you can find an existing premade glibc for the 'mips(el)-linux-gnu' target, this is the minimal amount of 'bootstrap' material to start with. Of course you can try to find premade binaries for GCC and for your precise host, but at least on Linux/x86 any premade binaries "for Linux/x86" may have troubles to run, not so much binary compatability as for instance on that bad Windoze... However on RedHats, running binaries made for RH6.2 with glibc-2.1.3 should still succeed on RH7.x, 8.0 and 9.0... One starting point could be the Debian's ports for 'mips-linux-gnu' and 'mipsel-linux-gnu'. There are prebuilt glibc-2.3.x's and older glibc-2.2.5's on the Debian FTP sites. No crosstools maybe, only the native tools for binutils and GCC. The package format is the '.deb', which may sound unstandard and impossible to unpack unless one knows it being a package made with 'ar' and in it being the needed '.tar.gz' file with some 'installation info'....

I don't know about the Alchemy AU1550, how near or far it is the normal R3000/R4000 chips, but most probably the AMD webpages should tell what it is. Anyway producing a toolchain for a 'generic' mips(el)-linux-gnu target using some Debian glibc should succeed easily and later one can think what special options the Alchemy AU1550-specific glibc would require and then produce it...

BTW, there can also be Linux/MIPS ports for things like the U.S.A. "TiVo" VHS/video recorder replacement and they may already use that Alchemy AU1550, so maybe AMD tells where their chips are now used and you can find a Linux port from these products...

The main problems with producing toolchains are quite newbie- like: not knowing where a cross-GCC has its stuff (comparable to not knowing where are the engine, battery and gasoline in a car...), not knowing that the 'libc.so' in Linux isn't a real shared library but a script having absolute paths in the library names, not knowing that Linux has also the so called 'kernel headers' which don't belong to glibc but to the Linux kernel -- in Debian glibcs they come with their glibc though, just read the FAQ...

So if you aren't yet familiar with the GCC options for absolute dummies like '--help' and '-print-search-dirs', then please learn them! It is assumed that any GCC user can at least look where GCC searches its needed stuff... Seeing the headers search paths may need some know-how, like that it isn't 'gcc' which needs the headers but 'cpp' or 'cc1*' where the 'cpp' is now, so a 'mips-linux-gnu-cpp -v' or something should tell the C headers search paths, but getting the C++ headers search paths may require using:

mips-linux-gnu-cpp -Wp,-lang-c++,-v (gcc-3.2.x and earlier) or `mips-linux-gnu-gcc -print-prog-name=cc1plus` -v (gcc-3.3....)

So the main advice is: Learn to know Linux and GCC, then producing GCC tools for Linux is much, much easier! Also learn to know your precise Linux/MIPS target, which GCC options one must use for it in different cases...

Another thing recently learned by me and the person who had problems with it, is that seemingly the Linux kernel and all those kernel modules for 'mips(el)-linux-gnu' must be produced as non-PIC code, meanwhile everything in the 'user mode' or in the produced tools and apps must always be PIC-code (this known already). That kernels or kernel modules shouldn't be produced with the GCC defaults (for PIC code) seemingly is in some FAQ but if being unread, it can cause very bad problems... So please use enough time to learn things like this from the FAQs for Linux/MIPS instead of using the usual way: "Switch the power on and then see where the smoke rises..." Cheers, Kai

Hello, Kai! You wrote on Thu, 15 Jul 2004 12:08:00 +0300:

??>> demand to use different versions of binutils/gcc/glibc and so on and ??>> might take really a LOT OF time, so I would like to take ??>> the ready-to-use toolchain.

KR> Building a cross-GCC for Linux shouldn't be any harder than building KR> a cross-GCC for any other system target, ie. a target which has a KR> native-GCC available for it. In this case the cross-GCC is only an KR> incarnation of the native-GCC on another host... What makes it KR> hard is that this fact is not understood and too many people think

What specific versions of binutils, gcc, glibc can you recommend? Are there any essential patches for them I should apply (if so, where to get them)? Searching in the google lead me to the following package versions:

gcc-2.95.3 binutils-2.11.2 glibc-2.2.3 + linuthreads

When I was building toolchain for ARM platform I used almost the same combination, except binutils were 2.10.1 and I don't remember any issues - but in this case I have another CPU, another architecture etc.

And at last -

Thanks in advance.

With best regards, Roman Mashak. E-mail: snipped-for-privacy@tusur.ru