Re: toolchain requirements submission

[Daniel Kegel <dank at kegel dot com>]

Greg Ungerer wrote:
> > > Something that I like in my ARM toolachains is to support both big and
> > > little endian target generation from the one installation set. I mean
> > > with full glibc for both. I don't see many other people talk about this,
> > > is this not something others do or need?  On a daily basis I build 
> > > for both big and little endian ARM platforms, and I really don't want 
> > > two full arm-linux toolchains installed.
> >
> >
> > That's called multilibbing, or biarch, or something like that.
> > It's a nice feature.  At some point, I'd like to see that in crosstool.
> > If anyone wants to volunteer to add it in a nice way, go right ahead!
>
>
> Well, I don't volunteer to do it :-)
> But I do it this way now for my arm-linux tools. It is not
> difficult, you do need to compile glibc for each multilib type,
> and you need to organize each glibc build to have the correct
> libdir setup.

Right.  I recall now that Debian (or some other distro) is
planning to switch to "multiarch" support (more general than biarch,
which I think specifically means 32 + 64 bit support).  We should
watch what they do with regards to where the libraries end up,
and maybe use the same scheme.

> > And the workaround, of having multiple toolchains installed, isn't
> > *that* painful given how large hard disks are these days.)
>
>
> This gets out of control very quickly once you start to look at
> a couple of different multilib setups. I need a setup now that
> lets me generate big/little endian and both hard/soft float. That
> would mean 4 separate tool chains for all combinations.
>
> The arm-elf I use for uClinux also does big/little endian and
> pic/non-pic. I really need it to do hard/soft float as well.
> So 6 combinations.
>
> I currently have 6 different CPU architecture compilers installed
> and in regular use on my dev system. As you can see, separate
> compilers for each combination would get silly very quickly.

Yep.  But you're still not hurting irretrievably.  And if you do
start to hurt bad, why, I guess you have an itch to scratch!

> The gcc multilib support is good. It is the building of glibc
> (or uClibc) for the combinations where I usually have to fix
> things up.

Right.  BTW I tend to disable multilib in my own testing, haven't
really gotten comfortable with it yet, it has had a couple problems.
I look forward to getting that right someday, too.
(I did get my head wrapped around it once, and even posted a patch
to add multilib support for ppc405, which thankfully was not approved...)
- Dan


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