Re: fpa glibc-2.2.5 for a native armv4l toolchain

[Kai Ruottu <karuottu at mbnet dot fi>]

Hayden Thring wrote:
> I've been working on a native fpa toolchain including gcc-2.95.3 and glibc-2.2.5, for a strongarm sa1110 which is detected as armv4l-unknown-linux-gnu.
>
> its currently running a vfp toolchain that can run both fpa and vfp binaries through floating point emulation.
>
> I also have an sdk for the os it runs that comes with a vfp cross compiler. (pdaxrom beta1)
>
> Im stuck now with trying to get glibc to compile as fpa rather than vfp, (for gcc-2.95.3 is default fpa)...
>   
Maybe using a totally default GCC made for 'arm-linux-gnu' would be a 
better choice.... Sites like 'www.scratchbox.org' are
providing standard and default GCCs for Linux/ARM.  Compiling one 
oneself isn't that hard either if one only knows the basics in
producing GCC ,like that the target binutils and the target C library 
must be preinstalled before trying to configure and build the
GCC sources.  The gcc-2.95.3 manual at least tries to tell these 
"basics" for all the newbies...

The GCC sources and the binutils sources should be easy to find...  Just 
as finding a prebuilt standard and default target C library
for Linux/ARM, for instance the Debian Linux provides prebuilt glibcs 
for Linux/ARM, including glibc-2.2.5.  Basically it could
be easy to ask "why" -  "Why you would like to rebuild a standard and 
default glibc-2.2.5 for Linux/ARM when a lazy person would
leave the Debian one being there at least for a while?".  I would be 
quite sure that the Debian one will include bugfixes etc. so a
plain vanilla glibc-2.2.5 made from the FSF sources isn't that 
'ready'...  But that is your choice, in any case the produced standard
and default gcc-2.95.3 for 'arm-linux-gnu' (bootstraped using the Debian 
glibc-2.2.5 for Linux/ARM) shouldn't give any problems
when using it to compile the glibc-2.2.5 sources!

> When i supply --without-fp to the glibc compile it succeeds (under vfp toolchain) but i end up with:
>
> 	# objdump -p crtend.o 
>
> 	crtend.o:     file format elf32-littlearm
> 	private flags = 600: [APCS-32] [VFP float format] [software FP]
>
>
> When im looking for:
>
> 	# objdump -p crtend.o 
>
> 	crtend.o:     file format elf32-littlearm
> 	private flags = 0: [APCS-32] [FPA float format]
>   

The 'crtend.o' comes in the GCC build, it is one of those C++ 
constructor/destructor handling startups, the 'crtbegin.o' is another....
Why you are taking this as an example from the objects in glibc when it 
has nothing to do with it?   Using the 'crt1.o', 'crti.o' or the
'crtn.o' (the 'csu' components) could tell something more sane...

> ***: Does whether im compiling glibc under a vfp crosschain or a fpa crosschain(gcc) effect this outcome?
>   
No, as was told the GCC build produces it!