fpu_control.h: Potentially using wrong include paths when building older glibc with newer cross-compiler

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Mon Aug 26 15:44:52 GMT 2024



On 25/08/24 22:22, Ahmad Bamba via Libc-help wrote:
> Hello all,
> 
> I'm trying to build a cross-compiler (x86_64-pc-linux-gnu ->
> mips64octeon-linux), and in doing so I'm trying to build glibc. I get the
> following error in the middle of building glibc 2.16.0 with the
> recently-built cross compiler while building -lm:
>    make[2]: Entering directory `/media/glibc-2.16.0/math'
>    /opt/cross/bin/mips64octeon-linux-gcc -mabi=n32
> ../sysdeps/mips/fpu/feholdexcpt.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall
> -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g
> -Wstrict-prototypes      -Wno-uninitialized  -mabi=n32 -D__NO_MATH_INLINES
> -D__LIBC_INTERNAL_MATH_INLINES -I../include -I/objdir-glibc/math
> -I/objdir-glibc -I../sysdeps/unix/sysv/linux/mips/mips64/n32/nptl
> -I../sysdeps/unix/sysv/linux/mips/mips64/n32
> -I../sysdeps/unix/sysv/linux/mips/mips64/nptl
> -I../sysdeps/unix/sysv/linux/mips/mips64
> -I../sysdeps/unix/sysv/linux/mips/nptl -I../sysdeps/unix/sysv/linux/mips
> -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread
> -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
> -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv
> -I../sysdeps/unix/mips/mips64/n32 -I../sysdeps/unix/mips/mips64
> -I../sysdeps/unix/mips -I../nptl/sysdeps/unix -I../sysdeps/unix
> -I../sysdeps/posix -I../sysdeps/mips/mips64/n32
> -I../sysdeps/ieee754/ldbl-128 -I../sysdeps/mips/mips64/soft-fp
> -I../sysdeps/mips/mips64 -I../sysdeps/ieee754/flt-32
> -I../sysdeps/ieee754/dbl-64 -I../sysdeps/mips -I../sysdeps/wordsize-32
> -I../sysdeps/mips/fpu -I../sysdeps/mips/nptl -I../sysdeps/ieee754
> -I../sysdeps/generic -I../nptl  -I.. -I../libio -I. -nostdinc -isystem
> /opt/cross/lib/gcc/mips64octeon-linux/13.3.1/include -isystem
> /opt/cross/lib/gcc/mips64octeon-linux/13.3.1/include-fixed -isystem
> /opt/cross/mips64octeon-linux/include/ -D_LIBC_REENTRANT -include
> ../include/libc-symbols.h  -DPIC -DNOT_IN_libc=1 -DIS_IN_libm=1
> -DIN_LIB=libm    -I../soft-fp -o /objdir-glibc/math/feholdexcpt.o -MD -MP
> -MF /objdir-glibc/math/feholdexcpt.o.dt -MT
> /objdir-glibc/math/feholdexcpt.o
>    In file included from ../include/fpu_control.h:1,
>                   from ../sysdeps/mips/fpu/feholdexcpt.c:21:
>    ../sysdeps/mips/fpu/feholdexcpt.c: In function ‘feholdexcept’:
>    ../sysdeps/mips/fpu_control.h:66:24: warning: statement with no effect
> [-Wunused-value]
>       66 | #define _FPU_GETCW(cw) 0
>          |                        ^

I seems that the compiler you are using for build glibc is targeting soft-fp
(__mips_soft_float)...

>    ../sysdeps/mips/fpu/feholdexcpt.c:29:3: note: in expansion of macro
> ‘_FPU_GETCW’
>       29 |   _FPU_GETCW (cw);
>          |   ^~~~~~~~~~
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:11: error: ‘_FPU_MASK_V’ undeclared
> (first use in this function)

... but was also configured to use hard-fp (the sysdeps/mipts/fpu existence
in path). 

Maybe you will need to either force glibc to not use hard-fp (--without-fp)
or configure the stage1 gcc to user hard-fp.

>       33 |   cw &=
> ~(_FPU_MASK_V|_FPU_MASK_Z|_FPU_MASK_O|_FPU_MASK_U|_FPU_MASK_I|FE_ALL_EXCEPT);
>          |           ^~~~~~~~~~~
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:11: note: each undeclared
> identifier is reported only once for each function it appears in
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:23: error: ‘_FPU_MASK_Z’ undeclared
> (first use in this function)
>       33 |   cw &=
> ~(_FPU_MASK_V|_FPU_MASK_Z|_FPU_MASK_O|_FPU_MASK_U|_FPU_MASK_I|FE_ALL_EXCEPT);
>          |                       ^~~~~~~~~~~
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:35: error: ‘_FPU_MASK_O’ undeclared
> (first use in this function)
>       33 |   cw &=
> ~(_FPU_MASK_V|_FPU_MASK_Z|_FPU_MASK_O|_FPU_MASK_U|_FPU_MASK_I|FE_ALL_EXCEPT);
>          |                                   ^~~~~~~~~~~
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:47: error: ‘_FPU_MASK_U’ undeclared
> (first use in this function)
>       33 |   cw &=
> ~(_FPU_MASK_V|_FPU_MASK_Z|_FPU_MASK_O|_FPU_MASK_U|_FPU_MASK_I|FE_ALL_EXCEPT);
>          |                                               ^~~~~~~~~~~
>    ../sysdeps/mips/fpu/feholdexcpt.c:33:59: error: ‘_FPU_MASK_I’ undeclared
> (first use in this function)
>       33 |   cw &=
> ~(_FPU_MASK_V|_FPU_MASK_Z|_FPU_MASK_O|_FPU_MASK_U|_FPU_MASK_I|FE_ALL_EXCEPT);
>          |
> ^~~~~~~~~~~
>    make[2]: *** [/objdir-glibc/math/feholdexcpt.o] Error 1
>    make[2]: Leaving directory `/media/glibc-2.16.0/math'
>    make[1]: *** [math/others] Error 2
>    make[1]: Leaving directory `/media/glibc-2.16.0'
>    make: *** [all] Error 2
> 
> Cross compiler information is as follows:
>    [root@7b1d394705f7 objdir-glibc]# /opt/cross/bin/mips64octeon-linux-gcc
> --version
>    mips64octeon-linux-gcc (GCC) 13.3.1 20240817
>    Copyright (C) 2023 Free Software Foundation, Inc.
>    This is free software; see the source for copying conditions.  There is
> NO
>    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> These _FPU_MASK macros seem to be defined in sysdeps/mips/fpu_control.h,
> which is in the the include path of the posted command. This tells me that
> the build may be getting to the system header first, located at
> /usr/include/fpu_control.h. But I'm super new to this and I'm not sure how
> to get gcc to ignore /usr/include, or consider it after it has considered
> these other include directories? The nostdinc flag is passed by default so
> I'm not sure what else to do.
> 
> This was my configure command:
>     CC=/opt/cross/bin/mips64octeon-linux-gcc
> CXX=/opt/cross/bin/mips64octeon-linux-g++ /media/glibc-2.16.0/configure
> --prefix=/opt/cross/mips64octeon-linux/ --build=$MACHTYPE
> --host=mips64octeon-linux
> --with-headers=/opt/cross/mips64octeon-linux/include/ --disable-multilib
> libc_cv_forced_unwind=yes
> 
> Unfortunately, the octeon device I am targeting has an old glibc and linux
> kernel version on it. For the purposes of this question, let's assume
> there's no way to update it or statically link glibc in my binaries.
> 
> Thanks in advance,
> Ahmad


More information about the Libc-help mailing list