Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Eli Zaretskii 
> Date: Thu, 21 Jul 2011 15:00:50 -0700
> From: Paul Eggert 
> CC: 9...@debbugs.gnu.org, bug-gnulib@gnu.org, 
>  Eli Zaretskii 
> 
> [...] if the benefit is large enough relative to the cost (something
> that's not clear to me).

People complain about bzr operations that take 15 seconds where git
takes 3, so I'm sure recovering 3 minutes of needless compilation will
be quite a win, at a cost of a couple of additional recipes in the
top-level Makefile.in.

Re: HAVE_RELIABLE_FIONREAD & ioctl

2011-07-21 Thread Bruno Haible 
Sam Steingold wrote:
> > +extern
> > +# ifdef __cplusplus
> > +"C"
> > +# endif
> > +DIR *fdopendir (int);
> 
> that's pretty awful.
> maybe there is a way to use the m4 magic to avoid replacing 1 line with 5?

Maybe. But the number of lines of a test program is not important to me;
it is much more important that the test program can be copy&pasted into
a .c file easily, for debugging. Therefore I'm against m4 macrology inside
test programs. (GL_NOCRASH is an exception: it can easily be omitted from
test programs.)

Bruno
-- 
In memoriam Ludwig Beck

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)

2011-07-21 Thread Herb Wartens 
On Thu, Jul 21, 2011 at 3:08 PM, Paul Eggert  wrote:

> On 07/21/11 02:16, Herb Wartens wrote:
> > OSX does have fdatasync defined as part of the libsystem_kernel.dylib
> library.
> > The problem is that there is no header on OSX that actually provides the
> function.
>
> Thanks again for reporting this.
>
>
No problem.



> What is the exact symptom of failure here?
> If 'configure' successfully linked to fdatasync, then
> presumably coreutils can link to it too.  So presumably
> your compiler complained about the missing declaration.
> But did it go ahead and use fdatasync anyway?  If so,
> we're done: you can just ignore the diagnostic.  If not,
>


I prefer to have my code always compile cleanly.  I have found that when
compiling code that generates a lot of warnings, people tend to ignore them
(even important ones).  The linker was able to resolve the fdatasync and
include it in the binaries:

# nm /usr/local/apps/Utils/coreutils/bin/dd | grep fdatasync
 U _fdatasync

# otool -L /usr/local/apps/Utils/coreutils/bin/dd
/usr/local/apps/Utils/coreutils/bin/dd:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
159.0.0)

# otool -L /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib:

/usr/lib/system/libsystem_kernel.dylib (compatibility version 1.0.0, current
version 1699.22.73)
 

# nm /usr/lib/system/libsystem_kernel.dylib | grep fdatasync
00017430 T _fdatasync



> perhaps 'configure' should check that fdatasync is declared
> (and not just linkable too), and use fdatasync only if it
> is declared; that would be more-conservative.
>
>
It would be more conservative, but we really could use it since we have it
defined in a library.  Unfortunately Apple did not include a header to
define it properly.  It's your call though as I would think either way is
fine (though some may prefer to actually have the fdatasync functionality).



> Have you checked, via "grep -r fdatasync /usr/include/", whether
> fdatasync is actually present anywhere?  It might be declared only
> if some other symbol is #define'd, in which case, we should find
> out what that is and #define it.
>


Yes I have checked, but I will leave you the results so that you
candouble-check me...=)
> grep -R fdatasync /usr/include
/usr/include/pg_config.h:/* Define to 1 if you have the declaration of
`fdatasync', and to 0 if you
/usr/include/pg_config.h:/* Define to 1 if you have the `fdatasync'
function. */
/usr/include/postgresql/internal/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/access/xlogdefs.h: * configure determined
whether fdatasync() is.
/usr/include/postgresql/server/c.h:extern int fdatasync(int fildes);
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the
declaration of `fdatasync', and to 0 if you
/usr/include/postgresql/server/pg_config.h:/* Define to 1 if you have the
`fdatasync' function. */
/usr/include/postgresql/server/port/linux.h: * Set the default
wal_sync_method to fdatasync.  With recent Linux versions,
/usr/include/postgresql/server/storage/fd.h:extern int pg_fdatasync(int fd);
/usr/include/python2.5/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.5/pyport.h:extern int fdatasync(int);
/usr/include/python2.6/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.6/pyport.h:extern int fdatasync(int);
/usr/include/python2.7/pyconfig.h:/* Define if you have the 'fdatasync'
function. */
/usr/include/python2.7/pyport.h:extern int fdatasync(int);
/usr/include/sys/syscall.h:#define SYS_fdatasync  187

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)

2011-07-21 Thread Herb Wartens 
On 07/21/11 02:16, Herb Wartens wrote:
>
> > I have added a hack to get coreutils to compile cleanly on OSX.
>
> Thanks, but we should fix this problem more cleanly.  Does the
> following patch to lib/stdint.in.h solve your problem?  This fix is
> already scheduled to appear in the next version of coreutils.  If it
> doesn't solve your problem, what are the symptoms of failure?
>
>
I agree.  Fixing it more cleanly would definitely be better!  The patch I
sent was a hack just to get coreutils compiling cleanly.  The patch you sent
does indeed remove the compiler warnings I was seeing when printing integers
with the PRIuMAX and PRIdMAX macros on OSX. I am still seeing the fdatasync
warnings though.

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Jim Meyering 
Bruno Haible wrote:
> Paul, Jim, Eric, others, do you remember other problems of stamp files?
>
>> The config.h rule (among others) has been using one for years,
>> and the last time I've heard complaints or bug reports about it
>> has been years also.
>
> For reference, here's the rules automake generates for config.h:
>
> config.h: stamp-h1
> @if test ! -f $@; then \
>   rm -f stamp-h1; \
>   $(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
> else :; fi
>
> stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
> @rm -f stamp-h1
> cd $(top_builddir) && $(SHELL) ./config.status config.h
>
> $(srcdir)/config.h.in:  $(am__configure_deps)
> ($(am__cd) $(top_srcdir) && $(AUTOHEADER))
> rm -f stamp-h1
> touch $@
>
> distclean-hdr:
> -rm -f config.h stamp-h1
>
> Is that the kind of rule you would recommend?

Hi Bruno,

I know of no problem with that time stamp mechanism.
It's been in use (complaint-free) for a very long time.

Re: HAVE_RELIABLE_FIONREAD & ioctl

2011-07-21 Thread Sam Steingold 
> * Bruno Haible  [2011-07-22 00:18:04 +0200]:
>
> -extern DIR *fdopendir (int);
> +extern
> +# ifdef __cplusplus
> +"C"
> +# endif
> +DIR *fdopendir (int);

that's pretty awful.
maybe there is a way to use the m4 magic to avoid replacing 1 line with 5?

-- 
Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 
11.0.60900031
http://memri.org http://www.PetitionOnline.com/tap12009/ http://dhimmi.com
http://camera.org http://mideasttruth.com http://honestreporting.com
DRM "access management" == prison "freedom management".

Re: HAVE_RELIABLE_FIONREAD & ioctl

2011-07-21 Thread Bruno Haible 
Sam Steingold wrote:
> > The problem that clisp/src/m4/ioctl.m4 tests against is fixed in Solaris 7
> > and newer, but is present in Solaris 2.6, FreeBSD 6.4, IRIX 6.5.
> 
> are they still "porting targets"?
> could you please move this to gnulib from clisp?

FreeBSD 6.4 is not so different from the newest FreeBSD 8.x; therefore I think
current FreeBSD has the same problem. And you surely don't want to drop FreeBSD
from clisp's porting targets.

> g++ -I/home/sds/src/top/include  
> -I/home/sds/src/clisp/sf/clisp/build-g-gxx/gllib -W -Wswitch -Wcomment 
> -Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare 
> -Wno-format-nonliteral -Wno-invalid-offsetof -falign-functions=4 -g -O0 
> -DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY 
> -DENABLE_UNICODE -DDYNAMIC_FFI -I. -c spvw.c
> /home/sds/src/clisp/sf/clisp/build-g-gxx/gllib/sys/ioctl.h:361: error: 
> declaration of C function 'int ioctl(int, int, ...)' conflicts with
> /usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
> unsigned int, ...)' here
> 
> $ grep REPLACE_IOCTL config.status
> S["REPLACE_IOCTL"]="0"
> ...
> configure:22838: checking for ioctl with POSIX signature
> configure:22855: g++ -c   conftest.c >&5
> configure:22855: $? = 0
> configure:22863: result: yes

OK, so because you are using a C++ compiler, gnulib's test for the ioctl()
prototype produced the wrong result (it did not detect a clash).

This should fix it and a couple of similar issues. Lesson to remember: When
we declare a system function with 'extern ...', we need to add a "C" linkage
specifier in C++ mode. Not needed for variables (at least with g++), because
the linkage of 'extern int foo;' and 'extern "C" int foo;' is the same.


2011-07-21  Bruno Haible  

Declare system functions in a way that works with C++.
* m4/fdopendir.m4 (gl_FUNC_FDOPENDIR) [C++]: In the test program,
declare fdopendir as extern "C".
* m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS) [C++]: In the test program,
declare frexpl as extern "C".
* m4/getaddrinfo.m4 (gl_GETADDRINFO) [C++]: In the test program,
declare gai_strerror as extern "C".
* m4/getdomainname.m4 (gl_FUNC_GETDOMAINNAME) [C++]: In the test
programs, declare gai_strerror as extern "C".
* m4/getlogin_r.m4 (gl_FUNC_GETLOGIN_R) [C++]: In the test program,
declare getlogin_r as extern "C".
* m4/ioctl.m4 (gl_FUNC_IOCTL) [C++]: In the test program, declare ioctl
as extern "C".
* m4/ldexpl.m4 (gl_FUNC_LDEXPL_WORKS) [C++]: In the test program,
declare ldexpl as extern "C".
* m4/logb.m4 (gl_FUNC_LOGB) [C++]: In the test programs, declare logb
as extern "C".
* m4/ls-mntd-fs.m4 (gl_LIST_MOUNTED_FILE_SYSTEMS) [C++]: In the test
program, declare getmntinfo as extern "C".
* m4/stpncpy.m4 (gl_FUNC_STPNCPY) [C++]: In the test program, declare
stpncpy as extern "C".
* m4/strerror_r.m4 (gl_FUNC_STRERROR_R_WORKS) [C++]: In the test
program, declare __xpg_strerror_r as extern "C".
* m4/strndup.m4 (gl_FUNC_STRNDUP) [C++]: In the test program, declare
strndup as extern "C".
* m4/sys_select_h.m4 (gl_HEADER_SYS_SELECT) [C++]: In the test program,
declare memset and bzero as extern "C".
Reported by Sam Steingold .

--- m4/fdopendir.m4.origThu Jul 21 23:55:04 2011
+++ m4/fdopendir.m4 Thu Jul 21 23:39:36 2011
@@ -1,4 +1,4 @@
-# serial 7
+# serial 8
 # See if we need to provide fdopendir.
 
 dnl Copyright (C) 2009-2011 Free Software Foundation, Inc.
@@ -26,7 +26,11 @@
 #include 
 #include 
 #if !HAVE_DECL_FDOPENDIR
-extern DIR *fdopendir (int);
+extern
+# ifdef __cplusplus
+"C"
+# endif
+DIR *fdopendir (int);
 #endif
 ]], [int result = 0;
  int fd = open ("conftest.c", O_RDONLY);
--- m4/frexpl.m4.orig   Thu Jul 21 23:55:04 2011
+++ m4/frexpl.m4Thu Jul 21 23:39:30 2011
@@ -1,4 +1,4 @@
-# frexpl.m4 serial 14
+# frexpl.m4 serial 15
 dnl Copyright (C) 2007-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -115,7 +115,11 @@
 # undef LDBL_MIN_EXP
 # define LDBL_MIN_EXP(-16381)
 #endif
-extern long double frexpl (long double, int *);
+extern
+#ifdef __cplusplus
+"C"
+#endif
+long double frexpl (long double, int *);
 int main()
 {
   int result = 0;
--- m4/getaddrinfo.m4.orig  Thu Jul 21 23:55:04 2011
+++ m4/getaddrinfo.m4   Thu Jul 21 23:39:56 2011
@@ -1,4 +1,4 @@
-# getaddrinfo.m4 serial 26
+# getaddrinfo.m4 serial 27
 dnl Copyright (C) 2004-2011 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -92,7 +92,11 @@
 #include 
 #endif
 #include 
-extern const char *gai_strerror(int);]])],
+extern
+#ifdef __cplusplus
+"C"
+#endif
+const char *gai_strerror(int);]]

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)

2011-07-21 Thread Paul Eggert 
On 07/21/11 02:16, Herb Wartens wrote:
> OSX does have fdatasync defined as part of the libsystem_kernel.dylib library.
> The problem is that there is no header on OSX that actually provides the 
> function.

Thanks again for reporting this.

What is the exact symptom of failure here?
If 'configure' successfully linked to fdatasync, then
presumably coreutils can link to it too.  So presumably
your compiler complained about the missing declaration.
But did it go ahead and use fdatasync anyway?  If so,
we're done: you can just ignore the diagnostic.  If not,
perhaps 'configure' should check that fdatasync is declared
(and not just linkable too), and use fdatasync only if it
is declared; that would be more-conservative.

Have you checked, via "grep -r fdatasync /usr/include/", whether
fdatasync is actually present anywhere?  It might be declared only
if some other symbol is #define'd, in which case, we should find
out what that is and #define it.

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Paul Eggert 
On 07/21/11 14:27, Bruno Haible wrote:
> What are, concretely, the problems you are fearing, or that you remember
> from the past? In other words, which are the tests that we should perform
> before committing a change that makes use of stamp files?

Your earlier message summarized the problems that I remember.
(Perhaps I've forgotten some.)  I'm afraid that the only reliable
way to test changes in this area is to have many Emacs developers
and installers, who use different styles, build Emacs and report
the problems that they see.  This would be a reasonable thing to
do, if the benefit is large enough relative to the cost (something
that's not clear to me).

Re: bug#9141: Coreutils Compiler Warnings on OSX 10.7 (Lion)

2011-07-21 Thread Paul Eggert 
[Adding bug-gnulib; the original bug report is .]

On 07/21/11 02:16, Herb Wartens wrote:

> I have added a hack to get coreutils to compile cleanly on OSX.

Thanks, but we should fix this problem more cleanly.  Does the
following patch to lib/stdint.in.h solve your problem?  This fix is
already scheduled to appear in the next version of coreutils.  If it
doesn't solve your problem, what are the symptoms of failure?

--- old/lib/stdint.in.h 2011-03-13 04:32:31.0 -0700
+++ new/lib/stdint.in.h 2011-07-21 14:47:33.901160610 -0700
@@ -272,6 +272,12 @@ typedef unsigned long int gl_uintptr_t;
 /* Note: These types are compiler dependent. It may be unwise to use them in
public header files. */
 
+/* If the system defines INTMAX_MAX, assume that intmax_t works, and
+   similarly for UINTMAX_MAX and uintmax_t.  This avoids problems with
+   assuming one type where another is used by the system.  */
+
+#ifndef INTMAX_MAX
+# undef INTMAX_C
 #undef intmax_t
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 typedef long long int gl_intmax_t;
@@ -282,7 +288,10 @@ typedef long long int gl_intmax_t;
 typedef long int gl_intmax_t;
 # define intmax_t gl_intmax_t
 #endif
+#endif
 
+#ifndef UINTMAX_MAX
+# undef UINTMAX_C
 #undef uintmax_t
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 typedef unsigned long long int gl_uintmax_t;
@@ -293,6 +302,7 @@ typedef unsigned long long int gl_uintma
 typedef unsigned long int gl_uintmax_t;
 # define uintmax_t gl_uintmax_t
 #endif
+#endif
 
 /* Verify that intmax_t and uintmax_t have the same size.  Too much code
breaks if this is not the case.  If this check fails, the reason is likely
@@ -433,8 +443,8 @@ typedef int _verify_intmax_size[sizeof (
 
 /* 7.18.2.5. Limits of greatest-width integer types */
 
+#ifndef INTMAX_MAX
 #undef INTMAX_MIN
-#undef INTMAX_MAX
 #ifdef INT64_MAX
 # define INTMAX_MIN  INT64_MIN
 # define INTMAX_MAX  INT64_MAX
@@ -442,13 +452,15 @@ typedef int _verify_intmax_size[sizeof (
 # define INTMAX_MIN  INT32_MIN
 # define INTMAX_MAX  INT32_MAX
 #endif
+#endif
 
-#undef UINTMAX_MAX
+#ifndef UINTMAX_MAX
 #ifdef UINT64_MAX
 # define UINTMAX_MAX  UINT64_MAX
 #else
 # define UINTMAX_MAX  UINT32_MAX
 #endif
+#endif
 
 /* 7.18.3. Limits of other integer types */
 
@@ -570,7 +582,7 @@ typedef int _verify_intmax_size[sizeof (
 
 /* 7.18.4.2. Macros for greatest-width integer constants */
 
-#undef INTMAX_C
+#ifndef INTMAX_C
 #if @HAVE_LONG_LONG_INT@ && LONG_MAX >> 30 == 1
 # define INTMAX_C(x)   x##LL
 #elif defined GL_INT64_T
@@ -578,8 +590,9 @@ typedef int _verify_intmax_size[sizeof (
 #else
 # define INTMAX_C(x)   x##L
 #endif
+#endif
 
-#undef UINTMAX_C
+#ifndef UINTMAX_C
 #if @HAVE_UNSIGNED_LONG_LONG_INT@ && ULONG_MAX >> 31 == 1
 # define UINTMAX_C(x)  x##ULL
 #elif defined GL_UINT64_T
@@ -587,6 +600,7 @@ typedef int _verify_intmax_size[sizeof (
 #else
 # define UINTMAX_C(x)  x##UL
 #endif
+#endif
 
 #endif /* !defined __cplusplus || defined __STDC_CONSTANT_MACROS */

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Bruno Haible 
Paul Eggert wrote:
> Like you, I'm leery of time stamp files; too often
> their costs outweigh their benefits.

What are, concretely, the problems you are fearing, or that you remember
from the past? In other words, which are the tests that we should perform
before committing a change that makes use of stamp files?

Bruno
-- 
In memoriam Ludwig Beck

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Paul Eggert 
On 07/21/11 03:57, Bruno Haible wrote:
> Is that the kind of rule you would recommend?

Yes, something like that might work, for config.status in Emacs.
But I'd rather not debug this sort of thing myself.
Like you, I'm leery of time stamp files; too often
their costs outweigh their benefits.

Re: HAVE_RELIABLE_FIONREAD & ioctl

2011-07-21 Thread Sam Steingold 
> * Bruno Haible  [2011-07-21 02:19:07 +0200]:
>
>> I pulled ioctl module from gnulib because of a compilation error about
>> "ioctl_used_without_requesting_gnulib_ioctl" and I am wondering whether
>> the HAVE_RELIABLE_FIONREAD et al are still relevant.
>
> The problem that clisp/src/m4/ioctl.m4 tests against is fixed in Solaris 7
> and newer, but is present in Solaris 2.6, FreeBSD 6.4, IRIX 6.5.

are they still "porting targets"?
could you please move this to gnulib from clisp?

>> Also, I get this error on linux:
>> 
>> /home/sds/src/clisp/sf/clisp/build-g-gxx/gllib/sys/ioctl.h:361: error:
>> declaration of C function 'int ioctl(int, int, ...)' conflicts with
>> /usr/include/sys/ioctl.h:42: error: previous declaration 'int
>> ioctl(int, long unsigned int, ...)' here
>> make: *** [spvw.o] Error 1
>> 
>> (after I removed the ioctl declaration from unix.h)
>> what's wrong?
>
> In this situation (on Linux, which has the non-POSIX declaration for ioctl())
> REPLACE_IOCTL should be set to 1 by config.status, so that gllib/sys/ioctl.h
> provides a declaration for rpl_ioctl, not ioctl. Somehow this is not 
> happening.
> Can you look in config.status what is the value of REPLACE_IOCTL? And if it is
> 0, look up in config.log the details of "checking for ioctl with POSIX 
> signature ..."

g++ -I/home/sds/src/top/include  
-I/home/sds/src/clisp/sf/clisp/build-g-gxx/gllib -W -Wswitch -Wcomment 
-Wpointer-arith -Wimplicit -Wreturn-type -Wno-sign-compare 
-Wno-format-nonliteral -Wno-invalid-offsetof -falign-functions=4 -g -O0 
-DDEBUG_OS_ERROR -DDEBUG_SPVW -DDEBUG_BYTECODE -DSAFETY=3 -DDEBUG_GCSAFETY 
-DENABLE_UNICODE -DDYNAMIC_FFI -I. -c spvw.c
/home/sds/src/clisp/sf/clisp/build-g-gxx/gllib/sys/ioctl.h:361: error: 
declaration of C function 'int ioctl(int, int, ...)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here

$ grep REPLACE_IOCTL config.status
S["REPLACE_IOCTL"]="0"

configure:13347: checking for sys/ioctl.h
configure:13347: g++ -c   conftest.c >&5
configure:13347: $? = 0
configure:13347: result: yes
configure:22829: checking for ioctl
configure:22829: g++ -o conftestconftest.c  >&5
configure:22829: $? = 0
configure:22829: result: yes
configure:22838: checking for ioctl with POSIX signature
configure:22855: g++ -c   conftest.c >&5
configure:22855: $? = 0
configure:22863: result: yes
configure:27876: checking whether  declares ioctl
configure:27893: g++ -c   conftest.c >&5
configure:27893: $? = 0
configure:27901: result: yes
configure:27971: checking whether ioctl is declared without a macro
configure:27993: g++ -c   conftest.c >&5
configure:27993: $? = 0
configure:28001: result: yes
configure:36146: checking for ioctl
configure:36146: result: yes
configure:36182: checking for ioctl declaration
configure:36204: g++ -c  -I/home/sds/src/top/include conftest.c >&5
configure:36204: $? = 0
configure:36235: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:466: error: declaration of C function 'char* ioctl()' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36235: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, unsigned int, 
char*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, int, char*)' 
conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, long unsigned 
int, char*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, long int, 
char*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, size_t, 
char*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/src/top/include conftest.c >&5
conftest.c:471: error: declaration of C function 'int ioctl(int, socklen_t, 
char*)' conflicts with
/usr/include/sys/ioctl.h:42: error: previous declaration 'int ioctl(int, long 
unsigned int, ...)' here
configure:36267: $? = 1
configure:36267: g++ -c  -I/home/sds/sr

Re: close depends on fclose?!

2011-07-21 Thread Eric Blake 

On 07/20/2011 06:00 PM, Bruno Haible wrote:

Hi Sam,


Why does close depend on fclose?!


The justification was in
.


It seems that, close being a system call and fclose being a C library
function, the dependency should be the other way around: fclose should
depend on close, but _NOT_ vice versa.


Yes, 'fclose' also depends on 'close'.


E.g., CLISP uses close but never FILE or fclose et al, so, when pulling
close, which pulled fclose, I got all these files which I will NEVER need


The assumption was that the vast majority of programs use stdio and fclose().
But I agree with you, it would be more in line with the gnulib principles
to let the programmer who needs specific features from fclose() to explicitly
request the 'fclose' module.

Any objections to removing this dependency?


None by me, as long as the fdopen/fclose pair still works on mingw sockets.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

Re: bug#9106: 24.0.50; ./configure causes massive recompilation

2011-07-21 Thread Bruno Haible 
Hi Ralf,

> I guess I don't understand why everyone hates stamp files.

I don't like them either [1], from past experience.

Maybe we need to look at the operations that are hurt by stamp files:

  - Building distributions. If stamp files are included in a tarball,
then merely unpacking the tarball (with 'cpio', not 'tar') or
copying it (with 'cp -r', not 'cp -a') sets the modification times
of all files, and the modification time of the stamp may end up
being a little bit earlier than the one of the main file.

  - Building on a NFS mounted file system, with a time shift between
the server and the client. The problem here was that "echo >> foo"
and "touch foo" assign different time stamps to the file 'foo'.

  - Removing or touching the main file by hand must cause a rebuild.
In some variants of the stamp rules, you also had to remove or
touch the stamp file in order to get "make" do something.

  - "make -n" ends up rebuilding things, while the developer does not
want "make -n" to do anything.

  - Or, "make -n" displays more or less statements than "make" will
actually execute. So "make -n" becomes unreliable.

Paul, Jim, Eric, others, do you remember other problems of stamp files?

> The config.h rule (among others) has been using one for years,
> and the last time I've heard complaints or bug reports about it
> has been years also.

For reference, here's the rules automake generates for config.h:

config.h: stamp-h1
@if test ! -f $@; then \
  rm -f stamp-h1; \
  $(MAKE) $(AM_MAKEFLAGS) stamp-h1; \
else :; fi

stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
@rm -f stamp-h1
cd $(top_builddir) && $(SHELL) ./config.status config.h

$(srcdir)/config.h.in:  $(am__configure_deps)
($(am__cd) $(top_srcdir) && $(AUTOHEADER))
rm -f stamp-h1
touch $@

distclean-hdr:
-rm -f config.h stamp-h1

Is that the kind of rule you would recommend?

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00045.html
-- 
In memoriam Ludwig Beck