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