[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patches] eglibc & powerpc-linuxspe-gcc (problem configuring/compiling eglibc svn trunk for mpc8540)
- To: Steven Munroe <munroesj@xxxxxxxxxx>
- Subject: Re: [patches] eglibc & powerpc-linuxspe-gcc (problem configuring/compiling eglibc svn trunk for mpc8540)
- From: "Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>
- Date: Mon, 10 Dec 2007 15:27:40 +0000 (UTC)
On Mon, 10 Dec 2007, Steven Munroe wrote:
> e500 is booke and is not powerpc. The common subset is --without-fp. So
> if you want e500 you have to configure --without-fp.
No, as explained a year ago when the E500 support was added to EGLIBC you
should use --with-fp for full support. And as explained there
<http://www.eglibc.org/archives/patches/msg00017.html> the ideal
arrangement would have been to move the existing directories to 6xx/fpu or
classic/fpu to reflect the existence of two different hardware
floating-point solutions on Power, and this was not done only to simplify
merges from FSF glibc. (This ideal arrangement mirrors what was done for
m68k/ColdFire.)
> I though I told these guys to define their own platform target?
EGLIBC should move towards less and less dependence on the nominal target
triplet name. This includes, for example, allowing 32-bit hard-float,
64-bit hard-float, 32-bit soft-float and 32-bit E500 all to be built with
a configuration as powerpc-linux-gnu, with the compiler properties tested
automatically to determine what multilib is in use and glibc configured
accordingly. Likewise i686-linux-gnu and x86_64-linux-gnu should be
interchangable. MIPS and m68k/ColdFire are good examples of preconfigure
scripts doing the right sort of tests for EGLIBC.
For EGLIBC we *did* put conditionals in common files rather than
artificially duplicate them because of the libc/ports division. In
particular, installed headers need to be suitable for all multilibs for an
architecture (and therefore contain appropriate conditionals) so that one
set of installed headers can be used with a compiler supporting several
multilibs (e.g. the four listed above).
--
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx