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

Re: math.h cross-compile: unhelpful error message

Hi Dima,

On Thu, Dec 23, 2021 at 02:14:42PM -0800, Dima Kogan wrote:
> Hi. This should probably be a bug report, but I'm not sure what package
> is responsible, so I'd like to ask here first.
> I just installed gcc-11-arm-linux-gnueabihf from unstable, but by
> mistake I have NOT installed libc6-dev:armhf. Only the native
> libc6-dev:amd64 is installed. This happens when building the one-line
> "#include <math.h>" source:
>   $ arm-linux-gnueabihf-gcc-11 -x c -c -o /dev/null <(echo '#include <math.h>')
>   In file included from /proc/self/fd/18:1:
>   /usr/include/bits/mathcalls-helper-functions.h:20:40: error: '_Float128' is not supported on this target
>      20 | __MATHDECL_ALIAS (int, __fpclassify,, (_Mdouble_ __value), fpclassify)
>         |                                        ^~~~~~~~~
>   /usr/include/bits/mathcalls-helper-functions.h:24:37: error: '_Float128' is not supported on this target
>      24 | __MATHDECL_ALIAS (int, __signbit,, (_Mdouble_ __value), signbit)
>   ... many more of these ...

gcc does not depend on a C library. The situation is not that much
different when performed natively:

$ gcc-11 -x c -c -o /dev/null <(echo '#include <math.h>')
/dev/fd/63:1:10: fatal error: math.h: No such file or directory
compilation terminated.

Exept for a shorter error message maybe.

> I guess it's picking up the amd64 headers instead of the armhf headers.
> Installing libc6-dev:armhf fixes it. I would expect an error message
> that says "You dummy. You need to install the arm-linux-gnueabihf flavor
> of math.h". Is this a bug for libc6-dev? Also, what do my Build-Depends
> need to have in order to pull in the correct header?

Yes, it is picking up amd64 headers. And yes, the fix is installing
libc6-dev:armhf. Indeed, there is a way to make the error message as
nice as it is natively. The key is to make the amd64 headers unavailable
to the cross compiler. It's done by moving them all to
/usr/include/<triplet>. That's #798955. It's mostly prepared, but at it
still breaks multilib and nobody has figured out why. As usual, it's
missing someone doing the work, unfortunately.

So yeah, it's all properly tracked already.


Reply to: