This is the mail archive of the mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: toolchain requirements submission

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, Want to unsubscribe? Send a note to

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]