limits.h header file in gcc-aarch64-linux-gnu is missing some identifiers

[nahwneeth]

Describe the bug
GCC cross compiler from package gcc-aarch64-linux-gnu fails to compile when referencing identifiers defined in <limits.h>.

To Reproduce
The following shows a simple C program which compiles with native GCC compiler but fails to compile with the GCC aarm64 cross compiler. It complains that the referenced identifier wasn't declared.

# docker run -it mcr.microsoft.com/cbl-mariner/base/core:2.0 /bin/bash

cd ~
tdnf update -y
tdnf install -y gcc glibc-devel binutils kernel-headers
tdnf install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu kernel-cross-headers

echo "
#include <limits.h>
int main() { return PATH_MAX; }
" > main.c

echo "compiling with gcc" && gcc main.c

echo "compiling with aarch64-linux-gnu-gcc" && aarch64-linux-gnu-gcc main.c

Expected behavior
The identifiers defined in <limits.h> should be accessible when cross compiling.

Screenshots

Why is this a AzureLinux bug?
The GCC Makefile produces a different <limits.h> file based on some conditions related to the build environment.

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/Makefile.in;hb=4b29be7216daa5921aae340388ef6416b1631f0a

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure;h=b4c52de6218406ddb00425a29b6effa5d6130d9c;hb=4b29be7216daa5921aae340388ef6416b1631f0a

For native targets, the system's limits.h file is found and the produced limits.h is a concatenation of limitx.h, glimits.h and limity.h files.

For cross targets, the system's limits.h file is not found as sys-root is configured due to which the produced limits.h is just the glimits.h file.

So, any identifiers that are defined as part of the limitx.h and limity.h files will be absent when building cross target. PATH_MAX for which this issue is open is one such identifier.

Versions tested with
OS: Mariner 2.0
gcc: 11.2.0-8.cm2.x86_64
gcc-aarch64-linux-gnu: 11.2.0-8.cm2.x86_64

[nahwneeth]

Just to add a data point, this compiles successfully on ubuntu. And similar to azure linux, this fails to compile on fedora.

# docker run -it ubuntu:24.04 /bin/bash

cd ~
apt update -y
apt install -y gcc binutils
apt install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu

echo "
#include <limits.h>
int main() { return PATH_MAX; }
" > main.c

echo "compiling with gcc" && gcc main.c
echo "compiling with aarch64-linux-gnu-gcc" && aarch64-linux-gnu-gcc main.c

# docker run -it fedora:41 /bin/bash

cd ~
yum update -y
yum install -y gcc binutils
yum install -y gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu

echo "
#include <limits.h>
int main() { return PATH_MAX; }
" > main.c

echo "compiling with gcc" && gcc main.c
echo "compiling with aarch64-linux-gnu-gcc" && aarch64-linux-gnu-gcc main.c

[nahwneeth]

In its current state, we cannot use the azure linux gcc cross compiler to cross compile golang code (that makes use of cgo) as the dlopen plugin in golang references PATH_MAX from limits.h - source. Getting this error from go:

[elsaco]

@nahwneeth on Fedora if you look at the gcc-aarch64-linux-gnu package info there's this paragraph in the Description section:

Only building kernels is currently supported.  Support for cross-building
user space programs is not currently provided as that would massively multiply
the number of packages.

So, now you know why buiding main.c fails on Fedora!

Ubuntu provides /usr/aarch64-linux-gnu/include/linux/limits.h part of linux-libc-dev-arm64-cross package. There's no such file on Fedora

[nahwneeth]

Thank you @elsaco for looking into the issue. It's unfortunate that building user-space programs is not supported. So, this seems to be intentional and not a bug. I'll mark it as a feature request for now while we explore other alternatives.

Edit: I'm not able to edit the labels. So, leaving it as bug.