limits.h problem in cross-toolchain

[Ozkan Sezer (sezeroz@gmail.com)]

In my linux hosted cross-djgpp toolchains, gcc-provided limits.h doesn't
include_next the djgpp-provided limits.h, I have to manually correct it.
cross-gcc is configured like:
./gcc-3.46/configure --prefix=/usr/local/cross-djgpp
--target=i586-pc-msdosdjgpp
--with-headers=/usr/local/cross-djgpp/i586-pc-msdosdjgpp/include
--enable-languages=c,c++ --disable-libgcj --disable-libada
--disable-nls

Same thing happens with gcc 3.3.6 and gcc 5.1.0 too. Before configuring
and building gcc, djgpp libs and headers are of course copied under
/usr/local/cross-djgpp/i586-pc-msdosdjgpp/

$ cat t.c
#include <limits.h>
#ifndef PATH_MAX
#error bad limits.h
#endif

If I don't correct the installed gcc limits.h myself, the above test surely
errors, which is annoying. What am I missing?

[Andris Pavenis (andris.pavenis@iki.fi)]

On 05/26/2015 11:43 PM, Ozkan Sezer (sez...@gmail.com) wrote:
> In my linux hosted cross-djgpp toolchains, gcc-provided limits.h doesn't
> include_next the djgpp-provided limits.h, I have to manually correct it.
> cross-gcc is configured like:

> ../gcc-3.46/configure --prefix=/usr/local/cross-djgpp

> --target=i586-pc-msdosdjgpp
> --with-headers=/usr/local/cross-djgpp/i586-pc-msdosdjgpp/include
> --enable-languages=c,c++ --disable-libgcj --disable-libada
> --disable-nls
>
> Same thing happens with gcc 3.3.6 and gcc 5.1.0 too. Before configuring
> and building gcc, djgpp libs and headers are of course copied under
> /usr/local/cross-djgpp/i586-pc-msdosdjgpp/
>
> $ cat t.c
> #include <limits.h>
> #ifndef PATH_MAX
> #error bad limits.h
> #endif
>
> If I don't correct the installed gcc limits.h myself, the above test surely
> errors, which is annoying. What am I missing?

Known problem. Also easy to avoid

Fragment from gcc/Makefile when building cross-compiler (on my Linux box)

# Default native SYSTEM_HEADER_DIR, to be overridden by targets.
NATIVE_SYSTEM_HEADER_DIR = /dev/env/DJDIR/include
# Default cross SYSTEM_HEADER_DIR, to be overridden by targets.
CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include

# autoconf sets SYSTEM_HEADER_DIR to one of the above.
# Purge it of unnecessary internal relative paths
# to directories that might not exist yet.
# The sed idiom for this is to repeat the search-and-replace until it doesn't match, using :a ... ta.
# Use single quotes here to avoid nested double- and backquotes, this
# macro is also used in a double-quoted context.
SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`

# Control whether to run fixincludes.
STMP_FIXINC = stmp-fixinc

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

Some variables in that Makefile:
libsubdir = $(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
gcc_tooldir = $(libsubdir)/$(libsubdir_to_prefix)$(target_noncanonical)

In short:

GCC build process expects system.h for prefix=/usr and target=i586-pc-msdosdjgpp
in $(prefix)/$(target)/sys-include but not $(prefix)/$(target)/include

The symptoms are as described in original message if DJGPP own limits.h is not found when
GCC build expects it be located

One can also take a look at RPM files I have put into directory /pub/djgpp/rpms and subdirectories
of ftp.delorie.com (files djcrx*.src.rpm and djcross-gcc-*.src.rpm).

Andris

[Ozkan Sezer (sezeroz@gmail.com)]

I see. So I tried symlinking or renaming the djgpp includes to
sys-includes and removing any --with-headers configury options, it
does work with gcc 5.1.0, but not with gcc 3.3.6 and 3.4.6 which I
use extensively. Oh the joys of configuring gcc..

Thanks.

--
O.S.