Will 'Bi-endian uClibc toolchain' be possible?

[Pradeep Sanchana]

Hi Rob,
Thanks for your reply.

> Gcc has enough trouble keep track of _one_ set of libraries to link
stuff 
> against, I really don't want to tax the little brain of its path logic
trying 
> to get it to keep track of two of anything.  

As suggested I have successfully built the uClibc libraries twice.
(i.e., for little 
Endian and for big Endian) prior to that I have successfully modified
the path
for the linker. (i.e., when you specify big Endian as target it will
look 
for big endian library files, and similarly for little Endian.). 
After this while I am building Final gcc, I am getting the error in 
uClibc header files.
Error is as follows:
--
In file included from
/home/shlinux/src/gcc-4.2.0/libmudflap/mf-hooks1.c:58:
/home/shlinux/build/run//sh4-linux/include/unistd.h:243: error: two or
more data types in declaration specifiers
make[4]: *** [mf-hooks1.lo] Error 1
-- 

Thanks & Regards,
Pradeep Sanchana

-----Original Message-----
From: Rob Landley [mailto:rob at landley.net] 
Sent: Friday, August 17, 2007 7:20 AM
To: uclibc at uclibc.org
Cc: Pradeep Sanchana; Khem Raj
Subject: Re: Will 'Bi-endian uClibc toolchain' be possible?

On Thursday 16 August 2007 3:44:27 am Pradeep Sanchana wrote:
> Hi Khem,
> Thanks for your reply.
>
> >> You have to build uclibc twice.
>
> Are you talking about single Endian multi variant support or bi-endian
> support?
>
> >> I am talking from ARM point of view sh might be
> >>different
>
> If you have build the 'bi-endian' or ' single endian multi variant'
ARM
> toolchain,
> kindly let me know the procedure to be followed, to build the same.

Personally, I just built two toolchains and called them armv5l-gcc and 
armv5lb-gcc or some such.

Gcc has enough trouble keep track of _one_ set of libraries to link
stuff 
against, I really don't want to tax the little brain of its path logic
trying 
to get it to keep track of two of anything.  However, if you did, you'd
have 
to build uClibc twice (once for each endianness) and install them in the

appropriate places that gcc could find each varient.

Where that would be is a gcc question, not a uClibc question.  Trying to

understand gcc's path logic falls under "things man was not meant to
know", 
check wikipedia for "Cthulu" before proceeding...

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.