Re: windows.h: No such file or directory
Eric Blake wrote on 2009-09-07: I'm pushing this, which improves the rename module (after first making the stdio module easier to modify) to cross-compile to non-mingw scenarios. ... --- a/lib/stdio.in.h +++ b/lib/stdio.in.h @@ -416,6 +416,20 @@ extern int putchar (int c); extern int puts (const char *string); #endif +#if @GNULIB_RENAME@ +# if @REPLACE_RENAME@ +# undef rename +# define rename rpl_rename +extern int rename (const char *old, const char *new); +# endif The identifier 'new' is a reserved word in C++ and leads to a syntax error here. I'm applying this fix: 2009-12-09 Bruno Haible br...@clisp.org Avoid syntax error in C++ mode. * lib/stdio.in.h (rename): Don't use parameter name 'new'. --- lib/stdio.in.h.orig 2009-12-10 14:08:02.0 +0100 +++ lib/stdio.in.h 2009-12-10 13:59:39.0 +0100 @@ -448,7 +448,7 @@ # if @REPLACE_RENAME@ # undef rename # define rename rpl_rename -extern int rename (const char *old, const char *new); +extern int rename (const char *old_filename, const char *new_filename); # endif #elif defined GNULIB_POSIXCHECK # undef rename
Re: windows.h: No such file or directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 8/22/2009 1:58 AM:
John Taylor wrote:
I'm trying to build coreutils-7.4 with a cross-compilator (gcc-4.4.1)
that runs on i686-unknown-linux-gnu and produces code for
x86_64-unknown-linux-gnu. When building coreutils, I get the following
error message:
../../coreutils-7.4/lib/rename.c:33:21: error: windows.h: No such file
or directory
...
That is an unfortunate consequence of the fact that the rename
module must perform a so-called run test to determine whether
it must work around certain rename bugs.
When cross-compiling, it assumes the worst.
However, in your case, the m4 macro could obviously do better,
knowing the target is linux/gnu-based.
A patch would be welcome.
I'm pushing this, which improves the rename module (after first making the
stdio module easier to modify) to cross-compile to non-mingw scenarios.
If we then follow through with my proposal to remove the rename-dest-slash
module in favor of rename, then the compilation error mentioned above
should also be solved. Then there's still the matter of writing a unit
test and improving behavior for other known or discovered bugs.
- --
Don't work too hard, make some time for fun as well!
Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkqlQ2UACgkQ84KuGfSFAYDNrQCghIVews7NvrqUxPGppwuGmmLJ
ZyEAniFCZalzsO+dGsbx135iqlkJuOdL
=ZDOK
-END PGP SIGNATURE-
From bd24844d02c2add6a689c2963d35b9f9bb216147 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Mon, 7 Sep 2009 05:51:20 -0600
Subject: [PATCH 1/3] getcwd: minor cleanups
* lib/getcwd.c (AT_FDCWD): Delete; rely on fcntl.h instead.
(is_ENAMETOOLONG): Delete; ENAMETOOLONG is portable.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog|4
lib/getcwd.c | 16 +---
2 files changed, 5 insertions(+), 15 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f7ac99c..771a9a9 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2009-09-07 Eric Blake e...@byu.net
+ getcwd: minor cleanups
+ * lib/getcwd.c (AT_FDCWD): Delete; rely on fcntl.h instead.
+ (is_ENAMETOOLONG): Delete; ENAMETOOLONG is portable.
+
openat: provide more convenience names
* modules/faccessat (configure.ac): Add C witness.
* lib/unistd.in.h (readlinkat): Fix typo.
diff --git a/lib/getcwd.c b/lib/getcwd.c
index 2da1aee..6658ed5 100644
--- a/lib/getcwd.c
+++ b/lib/getcwd.c
@@ -59,20 +59,6 @@
#include limits.h
-/* Work around a bug in Solaris 9 and 10: AT_FDCWD is positive. Its
- value exceeds INT_MAX, so its use as an int doesn't conform to the
- C standard, and GCC and Sun C complain in some cases. */
-#if 0 AT_FDCWD AT_FDCWD == 0xffd19553
-# undef AT_FDCWD
-# define AT_FDCWD (-3041965)
-#endif
-
-#ifdef ENAMETOOLONG
-# define is_ENAMETOOLONG(x) ((x) == ENAMETOOLONG)
-#else
-# define is_ENAMETOOLONG(x) 0
-#endif
-
#ifndef MAX
# define MAX(a, b) ((a) (b) ? (b) : (a))
#endif
@@ -164,7 +150,7 @@ __getcwd (char *buf, size_t size)
# undef getcwd
dir = getcwd (buf, size);
- if (dir || (errno != ERANGE !is_ENAMETOOLONG (errno) errno != ENOENT))
+ if (dir || (errno != ERANGE errno != ENAMETOOLONG errno != ENOENT))
return dir;
#endif
--
1.6.3.3.334.g916e1
From 1132a93bd6177115d1047846c62dc96fb7facb56 Mon Sep 17 00:00:00 2001
From: Eric Blake e...@byu.net
Date: Mon, 7 Sep 2009 10:16:42 -0600
Subject: [PATCH 2/3] stdio: sort witness names
* modules/stdio (Makefile.am): Sort replacements.
* m4/stdio_h.m4 (gl_STDIO_H_DEFAULTS): Likewise.
* lib/stdio.in.h: Likewise.
Signed-off-by: Eric Blake e...@byu.net
---
ChangeLog |5 +
lib/stdio.in.h | 631
m4/stdio_h.m4 | 104 +-
modules/stdio | 98 +-
4 files changed, 421 insertions(+), 417 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 771a9a9..e3af685 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2009-09-07 Eric Blake e...@byu.net
+ stdio: sort witness names
+ * modules/stdio (Makefile.am): Sort replacements.
+ * m4/stdio_h.m4 (gl_STDIO_H_DEFAULTS): Likewise.
+ * lib/stdio.in.h: Likewise.
+
getcwd: minor cleanups
* lib/getcwd.c (AT_FDCWD): Delete; rely on fcntl.h instead.
(is_ENAMETOOLONG): Delete; ENAMETOOLONG is portable.
diff --git a/lib/stdio.in.h b/lib/stdio.in.h
index 9dfb679..495baca 100644
--- a/lib/stdio.in.h
+++ b/lib/stdio.in.h
@@ -68,154 +68,6 @@
extern C {
#endif
-
-#if @GNULIB_FPRINTF_POSIX@
-# if @REPLACE_FPRINTF@
-# define fprintf rpl_fprintf
-extern int fprintf (FILE *fp, const char *format, ...)
- __attribute__ ((__format__ (__printf__, 2, 3)));
-# endif
-#elif @GNULIB_FPRINTF@ @REPLACE_STDIO_WRITE_FUNCS
Re: windows.h: No such file or directory
John Taylor wrote: I'm trying to build coreutils-7.4 with a cross-compilator (gcc-4.4.1) that runs on i686-unknown-linux-gnu and produces code for x86_64-unknown-linux-gnu. When building coreutils, I get the following error message: ../../coreutils-7.4/lib/rename.c:33:21: error: windows.h: No such file or directory ... That is an unfortunate consequence of the fact that the rename module must perform a so-called run test to determine whether it must work around certain rename bugs. When cross-compiling, it assumes the worst. However, in your case, the m4 macro could obviously do better, knowing the target is linux/gnu-based. A patch would be welcome. I found that I can fix this problem by adding gl_cv_func_rename_trailing_slash_bug=no to the configure arguments list. Is this the normal and recommended way to proceed? Are we in front of a bug, instead? You've done the right thing. Whenever you build using a cross-compiler, and for which an executable created by that compiler cannot be run on the host, you should manually seed the configure run with the ac_cv_* and gl_cv_* environment settings (cache variables) corresponding to those tests, so that the configure run-tests are not run at all. Since the configure script cannot determine whether your target system has a bug or feature, you must tell it via those cache variable settings.
windows.h: No such file or directory
Hello, I'm trying to build coreutils-7.4 with a cross-compilator (gcc-4.4.1) that runs on i686-unknown-linux-gnu and produces code for x86_64-unknown-linux-gnu. When building coreutils, I get the following error message: ../../coreutils-7.4/lib/rename.c:33:21: error: windows.h: No such file or directory ../../coreutils-7.4/lib/rename.c: In function 'rpl_rename': ../../coreutils-7.4/lib/rename.c:46: warning: implicit declaration of function 'MoveFileEx' ../../coreutils-7.4/lib/rename.c:51: warning: implicit declaration of function 'GetLastError' ../../coreutils-7.4/lib/rename.c:52: error: 'ERROR_FILE_EXISTS' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:52: error: (Each undeclared identifier is reported only once ../../coreutils-7.4/lib/rename.c:52: error: for each function it appears in.) ../../coreutils-7.4/lib/rename.c:52: error: 'ERROR_ALREADY_EXISTS' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:54: error: 'MOVEFILE_REPLACE_EXISTING' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:62: error: 'ERROR_FILE_NOT_FOUND' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:63: error: 'ERROR_PATH_NOT_FOUND' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:64: error: 'ERROR_BAD_PATHNAME' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:65: error: 'ERROR_DIRECTORY' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:69: error: 'ERROR_ACCESS_DENIED' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:70: error: 'ERROR_SHARING_VIOLATION' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:74: error: 'ERROR_OUTOFMEMORY' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:78: error: 'ERROR_CURRENT_DIRECTORY' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:82: error: 'ERROR_NOT_SAME_DEVICE' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:86: error: 'ERROR_WRITE_PROTECT' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:90: error: 'ERROR_WRITE_FAULT' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:91: error: 'ERROR_READ_FAULT' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:92: error: 'ERROR_GEN_FAILURE' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:96: error: 'ERROR_HANDLE_DISK_FULL' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:97: error: 'ERROR_DISK_FULL' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:98: error: 'ERROR_DISK_TOO_FRAGMENTED' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:107: error: 'ERROR_BUFFER_OVERFLOW' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:108: error: 'ERROR_FILENAME_EXCED_RANGE' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:112: error: 'ERROR_INVALID_NAME' undeclared (first use in this function) ../../coreutils-7.4/lib/rename.c:113: error: 'ERROR_DELETE_PENDING' undeclared (first use in this function) make[4]: *** [rename.o] Error 1 make[4]: Leaving directory `/mnt/clfs/sources/coreutils-build/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/mnt/clfs/sources/coreutils-build/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/clfs/sources/coreutils-build/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/mnt/clfs/sources/coreutils-build' make: *** [all] Error 2 I found that I can fix this problem by adding gl_cv_func_rename_trailing_slash_bug=no to the configure arguments list. Is this the normal and recommended way to proceed? Are we in front of a bug, instead? Thanks.
Re: windows.h: No such file or directory
On Friday 21 August 2009 16:53:55 John Taylor wrote: I'm trying to build coreutils-7.4 with a cross-compilator (gcc-4.4.1) that runs on i686-unknown-linux-gnu and produces code for x86_64-unknown-linux-gnu. When building coreutils, I get the following error message: ../../coreutils-7.4/lib/rename.c:33:21: error: windows.h: No such file or directory I found that I can fix this problem by adding gl_cv_func_rename_trailing_slash_bug=no to the configure arguments list. Is this the normal and recommended way to proceed? Are we in front of a bug, instead? it's a bug in the gnulib rename module. the failure you mention happens with just about every linux cross-compile target (and i doubt it's linux-specific). -mike signature.asc Description: This is a digitally signed message part.
