Send inn-workers mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."


Today's Topics:

   1. Re: 64bit time_t patch (Julien ?LIE)
   2. ptrdiff_t in CURRENT (Jeffrey M. Vinocur)
   3. Re: ptrdiff_t in CURRENT (Russ Allbery)
   4. Re: ptrdiff_t in CURRENT (Jeffrey M. Vinocur)
   5. Re: ptrdiff_t in CURRENT (Russ Allbery)
   6. Re: ptrdiff_t in CURRENT (Jeffrey M. Vinocur)
   7. Re: ptrdiff_t in CURRENT (Russ Allbery)
   8. Re: ptrdiff_t in CURRENT (Julien ?LIE)
   9. Re: ptrdiff_t in CURRENT (Jeffrey M. Vinocur)


----------------------------------------------------------------------

Message: 1
Date: Sun, 15 Dec 2013 14:45:42 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: 64bit time_t patch
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed

Hi,

>>> "S.P.Zeidler" writes:
>>>
>>> (64bit time_t on a 32bit machine)
>
> -            (long) (atimes/total) + starttime
> +            (long) ((atimes/total) + starttime)
>
> -  d_printf (1,"Preparing wake %d at date %ld for %d seconds\n",
> -           (int) id, (long) now, timeToWake - now) ;
> +  d_printf (1,"Preparing wake %d at date %ld for %ld seconds\n",
> +           (int) id, (long) now, (long) (timeToWake - now)) ;

By the way, did you try to build CURRENT (trunk) using "make warnings" 
instead of "make" on your system?
Maybe some of these issues are triggered off by gcc (for instance by the 
"format" warning).  Also, though not enabled by default by "make 
warnings", you could try to add "-Wconversion -Wno-sign-conversion" to 
the WARNINGS variable in Makefile.global and remove "-Werror" so that 
the build does not stop upon finding an error.  Maybe it will catch a 
few of these implicit wrong conversions on your system...

-- 
Julien ?LIE

? On dirait que Bonemine lui a tap? dans l'?il. ? (Ast?rix)


------------------------------

Message: 2
Date: Sun, 15 Dec 2013 16:49:29 -0500 (EST)
From: "Jeffrey M. Vinocur" <[email protected]>
To: [email protected]
Subject: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

I thought I would trying building CURRENT since everyone else was, and 
discovered this instead:

gcc -g -O2 -I../include  -c setproctitle.c
In file included from setproctitle.c:16:
../include/clibrary.h:134: error: conflicting types for 'ptrdiff_t'
/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/stddef.h:149: note: previous 
declaration of 'ptrdiff_t' was here
make[1]: *** [setproctitle.o] Error 1


The implicated bit of clibrary.h is below, interestingly the implicated 
bit of stddef.h has about a zillion ptrdiff-related #defines, but 
HAVE_PTRDIFF_T is not one of them.

     #if !HAVE_PTRDIFF_T
     typedef long            ptrdiff_t;
     #endif

Linux 2.6.32-41-server #94-Ubuntu SMP Fri Jul 6 18:15:07 UTC 2012 x86_64


-- 
Jeffrey M. Vinocur
[email protected]


------------------------------

Message: 3
Date: Sun, 15 Dec 2013 13:57:26 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

"Jeffrey M. Vinocur" <[email protected]> writes:

> The implicated bit of clibrary.h is below, interestingly the implicated
> bit of stddef.h has about a zillion ptrdiff-related #defines, but
> HAVE_PTRDIFF_T is not one of them.

>     #if !HAVE_PTRDIFF_T
>     typedef long            ptrdiff_t;
>     #endif

That's provided by Autoconf in INN by:

    AC_CHECK_TYPES([ptrdiff_t])

During your configure output, what does it say about whether you have a
ptrdiff_t type?  And what does config.log say about that probe?

-- 
Russ Allbery ([email protected])              <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


------------------------------

Message: 4
Date: Sun, 15 Dec 2013 17:09:27 -0500 (EST)
From: "Jeffrey M. Vinocur" <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sun, 15 Dec 2013, Russ Allbery wrote:

> "Jeffrey M. Vinocur" <[email protected]> writes:
>
>> The implicated bit of clibrary.h is below, interestingly the implicated
>> bit of stddef.h has about a zillion ptrdiff-related #defines, but
>> HAVE_PTRDIFF_T is not one of them.
>
> During your configure output, what does it say about whether you have a
> ptrdiff_t type?  And what does config.log say about that probe?

checking for ptrdiff_t... yes

and

configure:21115: checking for ptrdiff_t
configure:21145: gcc -c -g -O2  conftest.c >&5
configure:21151: $? = 0
configure:21166: result: yes
...
ac_cv_type_ptrdiff_t=yes


-- 
Jeffrey M. Vinocur
[email protected]


------------------------------

Message: 5
Date: Sun, 15 Dec 2013 14:18:33 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

"Jeffrey M. Vinocur" <[email protected]> writes:

> checking for ptrdiff_t... yes

> and

> configure:21115: checking for ptrdiff_t
> configure:21145: gcc -c -g -O2  conftest.c >&5
> configure:21151: $? = 0
> configure:21166: result: yes
> ...
> ac_cv_type_ptrdiff_t=yes

Okay, that's weird.  That means config.h should define HAVE_PTRDIFF_T, so
I don't understand why that part of clibrary.h is being built.

-- 
Russ Allbery ([email protected])              <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


------------------------------

Message: 6
Date: Sun, 15 Dec 2013 17:52:08 -0500 (EST)
From: "Jeffrey M. Vinocur" <[email protected]>
To: Russ Allbery <[email protected]>
Cc: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sun, 15 Dec 2013, Russ Allbery wrote:

> "Jeffrey M. Vinocur" <[email protected]> writes:
>
>> checking for ptrdiff_t... yes
>
> Okay, that's weird.  That means config.h should define HAVE_PTRDIFF_T, so
> I don't understand why that part of clibrary.h is being built.

There is no mention of HAVE_PTRDIFF_T in config.h, just this:

/* Define to long if <sys/types.h> does not define. */
/* #undef ptrdiff_t */


-- 
Jeffrey M. Vinocur
[email protected]


------------------------------

Message: 7
Date: Sun, 15 Dec 2013 15:03:33 -0800
From: Russ Allbery <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii

"Jeffrey M. Vinocur" <[email protected]> writes:

> There is no mention of HAVE_PTRDIFF_T in config.h, just this:

> /* Define to long if <sys/types.h> does not define. */
> /* #undef ptrdiff_t */

That's really weird.  I definitely have:

/* Define to 1 if the system has the type `ptrdiff_t'. */
#define HAVE_PTRDIFF_T 1

in my config.h.

-- 
Russ Allbery ([email protected])              <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


------------------------------

Message: 8
Date: Mon, 16 Dec 2013 09:59:02 +0100
From: Julien ?LIE <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
        format="flowed"

Hi Jeffrey,

> There is no mention of HAVE_PTRDIFF_T in config.h, just this:
>
> /* Define to long if <sys/types.h> does not define. */
> /* #undef ptrdiff_t */

Could you please check in your configure.ac file that it properly uses:

AC_CHECK_TYPES([ptrdiff_t])

and not:

AC_CHECK_TYPE([ptrdiff_t], ,
     [AC_DEFINE([ptrdiff_t], [long],
          [Define to long if <sys/types.h> does not define.])])


It should have normally been the case since commit 9313 for STABLE 2.5
(or 9291+9298 for CURRENT) in July 2011:
     https://inn.eyrie.org/trac/changeset/9313


As your include/clibrary.h file contains:

/* In case <sys/types.h> does not define ptrdiff_t. */
#if !HAVE_PTRDIFF_T
   typedef long ptrdiff_t;
#endif

it should normally be good, but better check...

-- 
Julien ?LIE



------------------------------

Message: 9
Date: Mon, 16 Dec 2013 05:11:46 -0500 (EST)
From: "Jeffrey M. Vinocur" <[email protected]>
To: [email protected]
Subject: Re: ptrdiff_t in CURRENT
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

On Mon, 16 Dec 2013, Julien ?LIE wrote:

> Could you please check in your configure.ac file that it properly uses:
>
> AC_CHECK_TYPES([ptrdiff_t])

This is what I have.

Okay, so I ran autogen and now it compiles fine.  Don't laugh, but has 
regenerating configure always been part of building from CURRENT?  I have 
no recollection of needing to do it in the past.


-- 
Jeffrey M. Vinocur
[email protected]

------------------------------

_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers

End of inn-workers Digest, Vol 58, Issue 7
******************************************

Reply via email to