This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
>> So somehow gcc/glibc got built with FPA hardfloat? > Yes, since that is the default. You might get away with rebuilding > glibc using CC="arm-linux-gcc -msoft-float", but that could cause > other problems. > The real solution would be building gcc with multilib support, so it > builds three separate versions (i.e. FPA hardfloat, FPA softfloat and > VFP softfloat) of libgcc and the other runtimes, but I've never > understood how to do this with glibc... It doesn't seem to have > multilib support. Multilib has caused nothing but problems for me...I have steered away from it as much as possible. For developers who build for many different targets I can see the usefulness of it. For developers who target one platform with one FP type, one CPU, etc...I just don't see the benfit of multilib...am I missing something? Why would one want VFP softfloat. I spent some time researching VFP the other day and I still don't understand why it would/should be used in any case. So basically if I get gcc stage 1 to output softfloat by default, then build glibc with CC="arm-linux-gcc -msoft-float" I *should* end up with a softfloat libgcc + softfloat glibc? Thanks for all your help! -Dave ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |