cros chroot's ARM clang compiler error: "Assumed value of MB_LEN_MAX wrong" |
||||
Issue description
This invocation fails:
$ armv7a-cros-linux-gnueabi-clang -ffreestanding -O2 test.c -o test
In file included from test.c:2:
In file included from /usr/aarch64-cros-linux-gnu/usr/include/stdlib.h:966:
/usr/aarch64-cros-linux-gnu/usr/include/bits/stdlib.h:143:3: error: "Assumed value of MB_LEN_MAX wrong"
# error "Assumed value of MB_LEN_MAX wrong"
Contents of test.c:
$ cat test.c
#include <limits.h>
#include <stdlib.h>
int main() {
return 0;
}
This error does not occur with armv7a-cros-linux-gnueabi-gcc. It also does not happen if either -O2 or -ffreestanding is ommited. Upon inspection of gcc's and clang's respective builtin include paths, it seems that the "/usr/lib64/clang/5.0.0/include" before "/usr/armv7a-cros-linux-gnueabi/usr/include" is unique to clang:
$ armv7a-cros-linux-gnueabi-gcc -E -x c++ -
<snip>
/usr/lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4
/usr/lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4/armv7a-cros-linux-gnueabi
/usr/lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4/backward
/usr/lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include
/usr/lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include-fixed
/usr/armv7a-cros-linux-gnueabi/usr/include
</snip>
$ armv7a-cros-linux-gnueabi-clang -E -x c++ -
<snip>
/usr/bin/../lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4
/usr/bin/../lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4/armv7a-cros-linux-gnueabi
/usr/bin/../lib/gcc/armv7a-cros-linux-gnueabi/4.9.x/include/g++-v4/backward
/usr/lib64/clang/5.0.0/include
/usr/armv7a-cros-linux-gnueabi/usr/include
</snip>
And the difference between the respective limits.h files:
/usr/armv7a-cros-linux-gnueabi/usr/include/limits.h:#define MB_LEN_MAX 16
/usr/lib64/clang/5.0.0/include/limits.h:#define MB_LEN_MAX 1
It seems like the fix would be to move the "/usr/lib64/clang/5.0.0/include" to the bottom of the builtin includes list, but I'm not sure if that's right or how to do that.
,
Jun 7 2017
,
Jun 7 2017
I think the bug is sort of tricky to trigger. I only discovered it when trying to make the rustc ebuild work with USE=clang. I think the '-ffreestanding' flag is also rarely used. That being said, it's P3 because that's just the default and I think I can work around it.
,
Jun 7 2017
you're using -ffreestanding which, imo, means you get the pieces. you can't use glibc (stdlib.h) & freestanding together.
,
Jun 8 2017
If you think this is a WontFix, can you mark it as such? I still find this behavior inconsistent, especially with respect to the fact that '-O2' has to be added to trigger this behavior. Also you can include stdlib.h without limits.h and it compiles. You can also include limits.h after stdlib.h and it compiles. This even works properly with gcc.
,
Jun 8 2017
i don't find the diff in behavior between optimization levels surprising ... glibc has many such checks where it changes things based on that as for it sometimes working depending on which includes or which order, i'm not sure that's worth getting into either ... you just got lucky some of the time ? :) we know -ffreestanding is not compatible with C lib headers and a toolchain that assumes a specific runtime env (glibc+linux). i didn't close the bug as i assumed this reduced testcase was where you arrived from a diff issue, and that other issue is really what you wanted addressed. but if you're all set, we can close this out.
,
Jun 8 2017
It seems that the code in rustc that uses -ffreestanding is being more aspirational than strict with its freestanding nature. It uses <stdlib.h> in order to use abort() in clear violation of freestanding. I'll just patch the ebuild and close this bug.
,
Jun 9 2017
thanks. |
||||
►
Sign in to add a comment |
||||
Comment 1 by llozano@chromium.org
, Jun 7 2017