• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 20 subscribers
  • Views 1652 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

include limits.h on arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi (is this a bug?)

mastupristi1

hello,

I use arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi on linux host.

I need `PATH_MAX` symbol that usually I get including (directpy or indirectly) limits.h. It the include sys/syslimits.h that actually defines PATH_MAX.

until version 10.3 (which I was using previously), including limits.h would load the file lib/gcc/arm-none-eabi/10.3.1/include-fixed/limits.h which in turn includes lib/gcc/arm-none-eabi/10.3.1/include-fixed/syslimits.h which finally (via #include_next) includes arm-none-eabi/include/limits.h (which allows PATH_MAX to be declared).
In the latest 11.3 release, however, the file lib/gcc/arm-none-eabi/11.3.1/include-fixed/limits.h does not include any other files, so the chain of inclusions is not triggered. And I have no way to directly include the file arm-none-eabi/include/limits.h.
Trying to include syslimits.h (that makes lib/gcc/arm-none-eabi/11.3.1/include-fixed/syslimits.h to be included) instead I get an error:

/opt/arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi/arm-none-eabi/include/limits.h:132:26: error: no include path in which to search for limits.h
  132 | # include_next <limits.h>
      |


The only way I have is to include sys/syslimits.h. But is this really the way to do it?


best regards

Max

Parents
  • 0

    I investigated further, comparing the toolchains gcc-arm-none-eabi-10.3-2021.07 and arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi (and their sources).

    The lib/gcc/arm-none-eabi/10.3.1/include-fixed/limits.h file is what I'm interested in in this context and what changes between the two versions.

    In the old version that file has two inclusions that are not there in the new version, and they are exactly what I need.

    Looking in the gcc sources I saw that the limits.h file can be the concatenation of gcc/limitx.h, gcc/glimits.h and gcc/limity.h or just the gcc/glimits.h file, here is a Makefile.in chunk:

    	  if $(LIMITS_H_TEST) ; then \
	    cat $(srcdir)/limitx.h $(srcdir)/glimits.h $(srcdir)/limity.h > tmp-xlimits.h; \
	  else \
	    cat $(srcdir)/glimits.h > tmp-xlimits.h; \
	  fi; \

    the choice depends on the value of LIMITS_H_TEST which is still populated in the makefile:

    # Test to see whether <limits.h> exists in the system header files.
LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]

    I bet <limits.h> file in the system header files is provided by newlib. Evidently when gcc is compiled, newlib has not yet been compiled/installed, so the <limits.h> file turns out not to be present and thus the include-fixed/limits.h file is generated using only gcc/glimits.h with no other inlcusions in it.

    I took a look at the compilation of toolchain 10.3, in fact among other things the compilation order is:

    • [...]
    • gcc-first
    • binutils
    • newlib
    • newlib-nano
    • gcc-final
    • [...]

    So when gcc-final is compiled, the newlib has already been compiled and therefore LIMITS_H_TEST is true.

    Instead looking at the file arm-gnu-toolchain-arm-none-eabi-abe-manifest.txt, if I understand correctly, and the order is followed, gcc is compiled before newlib.

    That might explain it.

    Is this a bug?

    best regards

Reply
  • 0

    I investigated further, comparing the toolchains gcc-arm-none-eabi-10.3-2021.07 and arm-gnu-toolchain-11.3.rel1-x86_64-arm-none-eabi (and their sources).

    The lib/gcc/arm-none-eabi/10.3.1/include-fixed/limits.h file is what I'm interested in in this context and what changes between the two versions.

    In the old version that file has two inclusions that are not there in the new version, and they are exactly what I need.

    Looking in the gcc sources I saw that the limits.h file can be the concatenation of gcc/limitx.h, gcc/glimits.h and gcc/limity.h or just the gcc/glimits.h file, here is a Makefile.in chunk:

    	  if $(LIMITS_H_TEST) ; then \
	    cat $(srcdir)/limitx.h $(srcdir)/glimits.h $(srcdir)/limity.h > tmp-xlimits.h; \
	  else \
	    cat $(srcdir)/glimits.h > tmp-xlimits.h; \
	  fi; \

    the choice depends on the value of LIMITS_H_TEST which is still populated in the makefile:

    # Test to see whether <limits.h> exists in the system header files.
LIMITS_H_TEST = [ -f $(BUILD_SYSTEM_HEADER_DIR)/limits.h ]

    I bet <limits.h> file in the system header files is provided by newlib. Evidently when gcc is compiled, newlib has not yet been compiled/installed, so the <limits.h> file turns out not to be present and thus the include-fixed/limits.h file is generated using only gcc/glimits.h with no other inlcusions in it.

    I took a look at the compilation of toolchain 10.3, in fact among other things the compilation order is:

    • [...]
    • gcc-first
    • binutils
    • newlib
    • newlib-nano
    • gcc-final
    • [...]

    So when gcc-final is compiled, the newlib has already been compiled and therefore LIMITS_H_TEST is true.

    Instead looking at the file arm-gnu-toolchain-arm-none-eabi-abe-manifest.txt, if I understand correctly, and the order is followed, gcc is compiled before newlib.

    That might explain it.

    Is this a bug?

    best regards

Children
No data