Eric Blake <e...@byu.net> writes: > According to Simon Josefsson on 3/24/2009 1:48 AM: >> Albert Chin <bug-gnu...@mlists.thewrittenword.com> writes: >> >>> With latest gnulib on HP-UX 10.20: >>> $ ./gnulib-tool --create-testdir --dir=t strtoull >>> $ cd t >>> $ ./configure >>> ... >>> $ gmake >>> ... >>> source='dummy.c' object='dummy.o' libtool=no \ >>> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \ >>> cc -Ae -DHAVE_CONFIG_H -I. -I.. -g -c dummy.c >>> source='strtoull.c' object='strtoull.o' libtool=no \ >>> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \ >>> cc -Ae -DHAVE_CONFIG_H -I. -I.. -g -c strtoull.c >>> cpp: "stdlib.h", line 52: error 4036: Can't open include file 'stdint.h'. > > That's weird. Line 52 of stdlib.in.h is #include <stdint.h>, so how is > that failing to find the system's stdint.h?
Maybe HP-UX 10.20 doesn't have a stdint.h. >>> gmake[4]: *** [strtoull.o] Error 1 >> >> stdlib.in.h needs stdint.h for struct random_data: > > I don't have access to HP-UX; are we sure that struct random_data is > defined in <stdint.h> on that platform? If so, it seems like the real bug > is that stdlib_h.m4 is not including <stdint.h> as one of the headers in > its probe for an existing struct random_data. I don't think so: struct random_data belongs in stdlib.h. However, to define the struct, you need int32_t which comes from stdint.h. I don't believe any system defines random_data in stdint.h -- if any does, we would get bug reports about it (and this bug report doesn't suggest this problem). >> So either we do: >> >> --- a/modules/stdlib >> +++ b/modules/stdlib >> @@ -9,6 +9,7 @@ Depends-on: >> include_next >> link-warning >> unistd >> +stdint > > Depending on what else we find, this seems like it is part of the solution > to me. Right. >> I can see the advantages in the second alternative, to avoid having >> gnulib's stdlib.h depend on stdint.h, but in the long run I'm not sure >> if it is worth it. > > Usually, if you're going to replace stdlib.h, the cost of replacing other > headers is not much more. I don't think we need a separate module. The only reason would be if someone wanted to use stdlib.in.h from gnulib and would not want to use stdint.in.h from gnulib -- if the application doesn't use struct random_data that would be possible. /Simon
