Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 178836 - uclibc-0.9.28.3 fails to build because CFLAGS="-msoft-float" is ignored
Summary: uclibc-0.9.28.3 fails to build because CFLAGS="-msoft-float" is ignored
Status: VERIFIED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Embedded Gentoo Team
URL: http://forums.gentoo.org/viewtopic-p-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-17 07:23 UTC by Christopher Friedt
Modified: 2007-05-19 07:54 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Friedt 2007-05-17 07:23:31 UTC
I'm trying to build (not cross-compile) the uClibc-0.9.28.3 on an arm (920T / cirrus ep9302) and the buid fails because the ebuild does not take CFLAGS="-msoft-float" into consideration.

My host machine is the target machine - i am not cross compiling. 

This is related to the forums.gentoo.org post here:

http://forums.gentoo.org/viewtopic-p-4060412.html#4060412

Code:
make[4]: Entering directory `/usr/portage/local/tinygentoo/tmpdir/portage/sys-libs/uclibc-0.9.28.3/work/uClibc-0.9.28.3/libc/sysdeps/linux/arm'                 
arm-softfloat-linux-uclibc-gcc  -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing  -mlittle-endian -mtune=arm9tdmi -march=armv4 -fno-stack-protector -fno-builtin -nostdinc -D_LIBC -I../../../../include -I.  -fstrict-aliasing -Os -funit-at-a-time   -isystem /usr/lib/gcc/arm-softfloat-linux-uclibc/3.4.4/include -DNDEBUG -fPIC  -c __longjmp.S -o __longjmp.o __longjmp.S: Assembler messages:                                               
__longjmp.S:36: Error: selected processor does not support `lfmfd f4,4,[ip]!'


This error corresponds to the source code located in uClibc/libc/sysdeps/linux/arm/__longjmp.S and if you take a look at that, then you'll see

Code:
#if defined __UCLIBC_HAS_FLOATS__ && ! defined __UCLIBC_HAS_SOFT_FLOAT__
        lfmfd   f4, 4, [ip] !   /* load the floating point regs */
#else
        add             ip, ip, #48             /* skip the FP registers */
#endif


The first condition, __UCLIBC_HAS_FLOATS__, corresponds to

Code:
Target Architecture Features and Options -->
[*] Enable floating point number support


or within the .config file UCLIBC_HAS_FLOATS=y .

The second condition corresponds to the event where gcc -msoft-floats is invoked. It is then safe to set HAS_FPU above, as long as -msoft-float is invoked with gcc.

Code:
Target Architecture Features and Options -->
[*]   Target CPU has floating point unit (FPU)


The 'Help' information for this option claims that it is OK to set HAS_FPU=y as long as you specify -msoft-float.

Code:
HAS_FPU:

If your target CPU does not have a Floating Point Unit (FPU) or a kernel FPU emulator, but you still wish to support floating point functions, then uClibc will need to be compiled with soft floating point support (-msoft-float).  If your target CPU does not have an FPU or an FPU emulator within the Linux kernel, then you should answer N.


I've enabled floating point emulation in my kernel, and so what I did, is before the emerge of uClibc, i set CFLAGS="-msoft-float". This had absolutely no effect in the emerge, even though CFLAGS="-msoft-float" appears when i do CFLAGS="-msoft-float" emerge --info. This is not a bug in gcc, but I would say that it's rather a bug in the ebuild file because it is ignoring a critical parameter.

If i set CFLAGS="-msoft-float" directly before an emerge, on the same line, I would expect that CFLAG to actually show up in the compiler. Likewise, if the option was present in make.conf.
Comment 1 SpanKY gentoo-dev 2007-05-19 05:12:57 UTC
softfloat targets need "softfloat" in the vendor field of the CHOST, nothing else is supported
Comment 2 Christopher Friedt 2007-05-19 07:54:54 UTC
I've read in a few places that -msoft-float is often faster than kernel FPU emulation, so I have no quabbles about just removing the HAS_FPU=y config. For my application we're using little to no floating point operations anyway.