Re: fpa glibc-2.2.5 for a native armv4l toolchain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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!


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux