bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building strtoull on HP-UX 10.20 requires stdint which is not includ


From: Simon Josefsson
Subject: Re: Building strtoull on HP-UX 10.20 requires stdint which is not included
Date: Tue, 24 Mar 2009 14:27:20 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux)

Eric Blake <address@hidden> writes:

> According to Simon Josefsson on 3/24/2009 1:48 AM:
>> Albert Chin <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]