Re: How to build glibc for ppc variant w/o floating point?

[Kai Ruottu <kai dot ruottu at luukku dot com>]

David Korn wrote:
> 
> >The above looks like it explains how to produce a gcc that doesn't
> >have floating point, but I'm more concerned about producing *glibc*
> >that doesn't have an floating point in it.  I can't see how modifying
> >the t-ppcgas file in gcc(since I'm using gas) can affect the code
> >genereated when building glibc.  I must be missing something here.
> 
>   Have you tried "make CFLAGS=-msoft-float" as well as configuring with
> --nfp ?  If that works, you'll have a no fpu libc, which you can install
> into the nof subdir of $prefix/$target/lib.  Then you'd want to reconfigure
> without the --nfp flag, do a build without the -msoft-float flag, and put
> it into the $prefix/$target/lib/fpu subdir.  I think the point of Kai's
> explanation was that if you had newlib, the gcc build process would make
> all the multilib variants for you and install them in the right places, but
> since glibc doesn't do that, you have to build the various multilib variants
> manually.

 My point was to say that if the '-msoft-float' is wanted for the only target,
perhaps it would be better to put it as the default. When it is used somewhere,
everything else must also be compiled using it, the Linux-kernel, glibc, the
libs coming with GCC, all the user programs and so on.

 But if the toolset is aimed to be generic and the '-mhard-float' is the
preferred default, remembering to use the '-msoft-float' everywhere when
building for the specific no-FPU target is also possible...

 I haven't tried to build glibc-2.2.2 with the '-msoft-float', so I don't
know what would happen in the build. Perhaps it is assumed everyone using
the FPU-emulator in the kernel and building glibc using the '-msoft-float'
will not succeed.

 BTW, the new names are 'FPBIT' and 'DPBIT' for the tmake_file, not 'FP-BIT'
and 'DP-BIT' as I wrote... And I haven't tried the 'ieeelib.c' instead of
the 'fp-bit.c/dp-bit.c' with PowerPC. The problem with it is that it will
be compiled as only two modules, 'fpieeelib.o' and 'dpieeelib.o', so
including possibly unnecessary routines, just as the 'fp-bit.o'/'dp-bit.o'
earlier... And the size-reduction seemed to be 4.1 kilobytes with a test
program which used both floats and doubles, not 20 kbytes, which I
remembered seeing with 'mips64*' targets recently... But a reduction from
100 k into 96 k (3 x 32 k) may be enough in the m68k- etc. worlds sometimes.

 What made me surprised was that gcc-2.95.3 was a bug-fix release, so the
new 'fp-bit/dp-bit'-handling should have been installed systematically for
every CPU-subdir in 'gcc/config', not only into some of them...

Cheers, Kai


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