Re: fpa glibc-2.2.5 for a native armv4l toolchain [resolved]

[Hayden Thring <hjthring at lavabit dot com>]

thanks for the prompt reply and information, just afetr i posted this i got working a arm-linux 2.95.3 (fpa) crosschain from handhelds.org and cross compiled glibc with that resulting in a fpa glibc :)

so i just copy that over to my host/target and "hook" it into my bootstrap gcc via the specs file and it works :)

alternatively i could have copied a glibc from another source such as debian but i was worried that i needed one compiled for the prefix it would reside at on my target... perhaps this is not an issue ?? as i did download a debian glibc earlier on but felt it could only go in / and this stuffed up my current glibc and subsequently the whole system resulting in a re-flash of the os.

as for the objdump examples, i did test the glibc see files but gave gcc examples in the post indirectly.

Hayden.


http://www.handhelds.org/download/projects/toolchain/archive/

On Sun, 01 Jul 2007 21:40:16 +0300
Kai Ruottu <karuottu@mbnet.fi> wrote:

> 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!
>