Hi David, I guess the solution here depends on the scope over which we expect the header to be used.
> On 28 Jan 2024, at 23:13, Iain Sandoe <i...@sandoe.co.uk> wrote: >> On 28 Jan 2024, at 21:25, Eric Gallager <eg...@gwmail.gwu.edu> wrote: >> On Sun, Jan 28, 2024 at 6:45 AM Iain Sandoe <iains....@gmail.com> wrote: >>> >>> Tested on i686, x86_64 Darwin, x86_64 Linux, >>> OK for trunk? >>> >>> --- 8< --- >>> >>> On some targets it seems that ssize_t is not defined by any of the >>> headers transitively included by <stdio.h>. This leads to a bootstrap >>> fail when jit is enabled. >>> >>> The fix proposed here is to include sys/types.h when it is available >>> since that is where Posix specifies that ssize_t is defined. >>> >>> gcc/jit/ChangeLog: >>> >>> * libgccjit.h: Conditionally include <sys/types.h> where it is >>> available to ensure declaration of ssize_t. >>> >>> Signed-off-by: Iain Sandoe <i...@sandoe.co.uk> >>> --- >>> gcc/jit/libgccjit.h | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h >>> index 235cab053e0..db4f27a48bf 100644 >>> --- a/gcc/jit/libgccjit.h >>> +++ b/gcc/jit/libgccjit.h >>> @@ -21,6 +21,9 @@ along with GCC; see the file COPYING3. If not see >>> #define LIBGCCJIT_H >>> >>> #include <stdio.h> >>> +#if __has_include(<sys/types.h>) >> >> Is __has_include() something that we can use unconditionally? > > Hmm.. maybe we cannot, it seems it was introduced in gcc-4.9 and we only ask > for 4.8, IIRC. > > I guess HAVE_SYS_TYPES_H might be an alternative (I’ll have to retest) Answering my own question; no that is not going to work either since the header is installed and config.h is not. I guess the question is “is this header ever [meaningfully] consumed by a compiler other than the current GCC that it supports”? e.g. if we expected we could build libgccjit with clang in a “—disable-bootstrap” configuration and expect that to work? The fallback is #ifdef __APPLE__ # include <sys/types.h> /* For ssize_t. */ #endif (which I will test on a number of platform versions). since this breaks bootstrap at stage 2 on affected platform versions, so we need some fix. thanks Iain
