On 2006-11-29 19:59 -0000, David Bisset wrote:
> >But I can't test them as not-debian boxes are not allowed in the house
> >:-) So can someone with a suitable machine download either:
> >http://www.emdebian.org/files/tools/tgz/gcc4.1-glibc2.3.6-binutils2.17->i38
> 6-arm-cross-toolchain.tgz
>
> OK I've downloaded this onto a Fedora Core 4 system (a little out of date
> but functional). This does not appear to contain arm-linux[c++ gcc cpp
> gccbug] ie all the useful stuff.
You mean this machine didn't previously contain those things, or the
tarball doesn't appear to contain them (it should).
> I've unwrapped it where I unwrap different tool chains which only required
> some minor dir name fiddling. However the structure of the directory tree is
> somewhat different (particularly the lack of include at the "top" and the
> way that different bits of the include tree are structured). This may of
> course simply reflect the changing world of gcc 4.1 or it may reflect a
> particular Debian view of the world, I'm not sure.
It is the latter. It should be unpacked at the top-level (so binaries
end up in /usr/bin, libs and includes in /usr/arm-linux-gnu/ etc.
If you do that, does it then work?
There are two sensible ways of setting up cross toolchains. One
assming everything will be put in /usr/local/gccfoo/ and one that
treats it like any other package and installs binaries in /usr/bin,
docs in /usr/share etc. The former is better if you want multiple
minor versions of toolchains on one machine, and select them with
$PATH, the latter is better if you just want to install a toolchain
and have it 'jsut work'. You can still install one of each major
version (gcc3.4, 3.3, 4.0 etc, and for each target arch). The default
is set using symlinks.
These packages use the latter method, which should suit most people.
> {I will now try the RPMs I assume that the .tgz was a tree snapshot after
> the .rpm s were unwrapped, except of course they were .deb s :-) )
Correct. it is a concatenation of all the files in the packages.
> >Note the cross prefix is now arm-linux-gnu- not just arm-linux- (to
> >distinguish from uclibc and gnueabi toolchains)
>
> This is a royal pain, as this string is embedded in countless application
> scripts and makefiles all over..., well all over everything. I think I will
> be using some symbolic links without the -gnu- bit.
This is inded something of a pain, but it's the way gcc is headed.
Everyone will get used to it after a while. Now that there are oldabi
and newabi compilers there has to be some way to distinguish.
I don't think it actually appears in that many places. I've found it
in the kernel makefile (once) and bootldr makefile (two lines).
Bootldr has been fixed in CVS to find it automatically. Anything that
uses autoconf will also get this right automagically. My impression so
far is that it's less of problem than you think.
Just put $(CROSS_COMPILE)$(CC) instead of arm-linux-gcc and it should
DTRT in most cases.
> On brief reflection this addition seems dumb. If you are building in a
> different way for the same machine then you want to parameterise the build
> (i.e. an eabi build and a non eabi build ) changing the executable name
> isn't the right way to define different build types. I don't want to have to
> change my application makefile moving from one build type to another, I want
> to parameterise it, or even point to where to find the right executables but
> I don't want them changing names. {The arm-linux prefix is of course valid
> and useful as I may have many different cross build environments.}
You can't have one compiler that does both old and new ABI (so far as
I can tell). They are considered different architectures. Different
compilers are called with different executable names (just the same as
m68k-linux- vs. arm-linux-) , so I think it is the right answer. On
debian you can use the 'alternatives' mechanism to choose which
compiler (ABI, gcc version) is the default. This is effectively just
symlinks. On other systems you probably get to change the symlinks
yourself.
I haven't yet checked that you can have arm-linux-gnu- and
arm-linux-gneabi- versions of the compiler installed at once and
everything works properly but you can cetainly have arm-linux- and
arm-linux-gnu- versions and that works OK.
But all this is something of a side-issue to the original question -
does the tarball or rpms work on an rpm-based system. I suspect the
only issue is 'does the glibc version match up sufficiently?'
Wookey
--
Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/ play: http://wookware.org/
(text/plain)